[pulseaudio-discuss] Multiple RTP Receivers not in sync

[Tanu Kaskinen]

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