audio chopped after running for several hours

[Paixao Julien]

> 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.
> 

Indeed I could now see that rtpjitterbuffer is estimating the clock skew between sender and receiver.
According to that estimation the GstBuffer are re-timestamped.

Next to that alsasink element will slave its internal clock with the master clock using the skew method in my case.

> 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.
> 

Thanks for your help Tim.

Best regards,
Julien.