audio chopped after running for several hours

[Paixao Julien]

> From: gstreamer-devel [mailto:gstreamer-devel-
> bounces at lists.freedesktop.org] On Behalf Of Peter Maersk-Moller
> Sent: Tuesday, January 26, 2016 1:17 PM
> To: Discussion of the development of and with GStreamer <gstreamer-
> devel at lists.freedesktop.org>
> Subject: Re: audio chopped after running for several hours
> 
> Hi Paixao.
> Synchronizing the clock of sender system and receiver system using NTP is
> also useful. This means running the ntp deaemon on both systems. Note that
> ntpd over time calculate the drift of the internal system clock and that may
> take some time to get right. Also note that the drift of an internal clock may
> change depending on temperature and perhaps other factors.
> Last but not least, some audio sources (audio cards, dsp etc.) may use their
> own internal clock to produce the sample rate rather than system clock. Here
> NTP will not help preventing drift. But GStreamer has a module named
> audiorate that may, if I am not mistaken, can produce an audiorate linked to
> the system clock and as described, the system clock might be adjusted by
> NTP to synchronize.
> Best Regards
> Peter
> 

NTP is running on both devices, the system clock is used by both pipelines.

> > [...]
> > You should insert an rtpjitterbuffer before the depayloader. Otherwise
> > your sender and receiver clocks will slowly drift apart until it
> > becomes an audible problem. Not sure if that is the problem in your
> > case, but it's something that is definitely going to happen so try that first.
> >
> 
> That's something I haven't thought about yet, I am now busy trying it.
> 

I am now using a network emulator between Device1 and Device2.
The IP packets from Device1 to Device2 are first going to the network emulator.

With this network emulator I can simulate some network effects.
One of them is the jitter and indeed by adding jitter on the line I start to have choppy audio since the pipeline of Device2 does not contain a jitter buffer before the depayloader.

I have also played with the delay parameter, a fixed delay is applied to each packet from Device1 to Device2.
I have tried a delay of 500ms, 1s and 2s.
Let's visualize the situation with a delay of 500ms:
Device1 -> Sends RTP packet1 at 0ms   ---------------  Device2 -> Receives RTP packet1 after 500ms
Device1 -> Sends RTP packet2 at 16ms ---------------  Device2 -> Receives RTP packet2 after 516ms
Device1 -> Sends RTP packet3 at 16ms ---------------  Device2 -> Receives RTP packet3 after 532ms
...

In that situation, seeing my Device2 pipeline, I would expect that all the packets arriving in Device2 would be dropped by the alsasink since max-lateness is set to 100ms.
But the audio on Device2 still plays smoothly, I do not understand that, it looks like the timestamp in the RTP packets is not used...
Would you have any ideas why?

Best regards,
Julien.