audio chopped after running for several hours

[Tim Müller]

On Fri, 2016-02-05 at 08:51 +0000, Paixao Julien wrote:

> But like it has been mentioned in this thread, between the two
> different IP devices the clock will drift.
> 
> By debugging the pipelines I could see that:
> - pipeline from device#1 is using the clock provided by the alsasrc.
> - pipeline from device#2 is using the clock provided by the system.
> 
> At some point it's possible that the clock of pipeline#2 will run
> slightly faster than the one on pipeline#1.
> What will happen is that the udpsrc element will start to buffer the
> packets coming in (in fact it's done on kernel level) since they are
> not consumed fast enough by the upper layer (GStreamer).
> And if the kernel buffer for udpsrc is full then packets will start
> to be dropped by the kernel.

This might happen if pipeline #2 (the receiver) is consuming data
*slower* than the sender is sending it, ie. the receiver clock is
running faster than the sender's.

However, this does not take into account the fact that there is an
rtpjitterbuffer in the pipeline. The rtpjitterbuffer will correlate the
sender time (in form of the RTP timestamps in the RTP packet headers)
and the local receiver time (in form of GstBuffer timestamps of the udp
packet received by udpsrc and timestamped according to the pipeline
clock). The jitterbuffer will fix up short-term jitter and calculate
long-term drift between sender and receiver clock, and timestamp the
outgoing packets accordingly. What happens then depends on how the
audiosink is configured (slave-method property) - either the audio sink
will skip/insert some samples every now and then to correct for the
drift, or it will resample the audio slightly if needed, and if so
configured.

So in short, the rtpjitterbuffer in combination with the sink should
take care of handling the drift.

I think you need to find out what exactly causes the 'choppiness' - are
timestamps going wrong, is the audiosink doing something weird, etc.?

I would also recommend you first try to make this work with a
desktop/laptop running the latest or a current version of GStreamer.
1.0.7 is quite old, and there were loads of bug-fixes since then. It
would be good for you to know that you have something that should work
and then you can investigate what fixes need to be backported.

 Cheers
  -Tim

-- 
Tim Müller, Centricular Ltd - http://www.centricular.com