On Fri, 2012-04-20 at 09:18 -0500, Pierre-Louis Bossart wrote:
On 4/15/2012 5:01 AM, Sebastian Stuecker wrote:
Hallo,
I am building a whole home audio solution with a central server that
has several mpd instances connected each to a pulseaudo null sink and
all those null sinks have their corrosponding RTP sender and use
different multicast IP adresses (parameter sap_address).
I have then multiple receiving units throughout my house and with them
i tune to the different rtp streams coming from the sender. Of
course I want to tune more than one receiver to the same RTP stream so
I listen to the same music in multiple rooms. Since those rooms are
adjacent to each other it is vital that the audio is in sync,
otherwise I have echoes or even larger lags which is very annoying.
As far as I understood the pulseaudio rtp implementation, those
receivers SHOULD be automatically in sync. I have an ntp daemon
running on all receivers and their sync to an ntp daemon running on
the server. I have manually checked clock sync and as far as NTP
precision goes, the clocks of all hosts (both sender and receivers)
are in perfect sync.
BUT, the sound is not. I have lags of up to 1-2 seconds. Everytime i
restart the pulseaudio daemon on a receiver the sync lag is different.
Sometimes it is in very good sync but then it looses sync over time.
Is there any way of debugging/tuning this? The logoutputs of the
sender and receivers look normal so they tell about rate adjustments
all the time but I understand this is the way how it just works.
Your receivers are not synchronized in terms of audio clocks, which will
induce a drift, and even NTP isn't accurate enough for synchronized
starts. Some day when the Ethernet AVB standard and its wireless
equivalent are deployed you'll be able to do this. For now there's no
non-proprietary solution.
I don't know what you mean by accurate enough, but the clock drift
doesn't have to result in 1-2 second delay. Pulseaudio is supposed to
resample the received data so that the sound card consumes it at the
same rate as the sending machine sends it. According to the above
description, this is not working as it should (a good sync gets bad over
time).
The problem with the random lag when restarting Pulseaudio might be a
separate problem... variable delay in the network, or maybe
module-rtp-recv creates a sink input and then waits for a variable time
to receive some key packet from the stream...
--
Tanu
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
