<div dir="ltr"><div><div><div><div>Hi Paixao.<br><br></div>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.<br><br></div>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.<br><br></div>Best Regards<br></div><div>Peter<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 26, 2016 at 10:51 AM, Paixao Julien <span dir="ltr"><<a href="mailto:J.Paixao@televic.com" target="_blank">J.Paixao@televic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> -----Original Message-----<br>
> From: gstreamer-devel [mailto:<a href="mailto:gstreamer-devel-">gstreamer-devel-</a><br>
> <a href="mailto:bounces@lists.freedesktop.org">bounces@lists.freedesktop.org</a>] On Behalf Of Sebastian Dröge<br>
> Sent: Monday, January 25, 2016 7:00 PM<br>
> To: Discussion of the development of and with GStreamer <gstreamer-<br>
> <a href="mailto:devel@lists.freedesktop.org">devel@lists.freedesktop.org</a>><br>
> Subject: Re: audio chopped after running for several hours<br>
><br>
> On Mo, 2016-01-25 at 14:16 +0000, Paixao Julien wrote:<br>
> > [...]<br>
> > I would be really glad to get any suggestions from the GStreamer<br>
> >devel mailing list members regarding this issue.<br>
><br>
> You should insert an rtpjitterbuffer before the depayloader. Otherwise your<br>
> sender and receiver clocks will slowly drift apart until it becomes an audible<br>
> problem. Not sure if that is the problem in your case, but it's something that<br>
> is definitely going to happen so try that first.<br>
><br>
<br>
</span>That's something I haven't thought about yet, I am now busy trying it.<br>
<span class=""><br>
> > FYI: I am using GStreamer version 1.0.7, the two devices are embedded<br>
> > devices where it's not so easy to upgrade the GStreamer package.<br>
><br>
> You should still try that as there were a lot of changes in the RTP stack since<br>
> then, and also in other elements.<br>
><br>
<br>
</span>Indeed.<br>
<br>
I am now trying to make a setup where the choppy audio is automatically detected (no need to check on a scope time to time).<br>
And also trying to find a reproduction scenario, since this issue only appears after several hours.<br>
<br>
I'll get back with more information.<br>
<br>
Best regards,<br>
Julien Paixao.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</div></div></blockquote></div><br></div>