<div dir="ltr">Hi!<div style=""><br></div><div style="">Thank you for your answer!</div><div style=""><br></div><div style="">I ended up using the gst_ntp_clock_new and it works good so far.</div><div style="">Sometimes you hear them drifting apart by a little (I guess about 50ms), but they are getting in sync again.</div><div style="">Maybe I will try to use a ptp clock source for further improvement, but im happy with that for the moment.</div><div style="">My problem now is, that i want to have the delay between the mic source and the remote sinks as small as possible.</div><div style=""><br></div><div style="">So i use</div><div style=""><br></div><div style="">  g_object_set(G_OBJECT(micsrc), "latency-time", (guint64)2000, NULL);</div><div><span style="white-space:pre">  </span>g_object_set(G_OBJECT(micsrc), "buffer-time", (guint64)20000, NULL);</div><div><br></div><div style="">for my directsoundsrc at the sender and </div><div style=""><br></div><div style=""><div>  g_object_set(G_OBJECT(audiosink), "latency-time", (guint64)2000, NULL);</div><div>  g_object_set(G_OBJECT(audiosink), "buffer-time", (guint64)50000, NULL);</div><div>  g_object_set(G_OBJECT(rtpbin), "latency", 200, NULL); <br></div><div style=""><br></div><div style="">for the alsasinks at the remote clients.</div><div style=""><br></div><div style="">The latency at the beginning is ok, with about 300ms, but as long as the stream is active it increases.</div><div style="">After 24 hours it was about 5 seconds and after 72 hours of live streaming it was about 25 seconds.</div><div style=""><br></div><div style="">Is there something wrong with my settings here. How can i stop the increasing latency and further reduce the overall latency of the pipeline?</div><div style=""><br></div><div style="">My pipeline uses following elements:</div><div style=""><br></div><div style="">  directsoundsrc ! audioconvert ! lamemp3enc ! rtpmpapay ! rtpbin ! udpsink_rtp  rtpbin ! udpsink_rtcp </div><div style=""><br></div><div style="">  udpsrc_rtp ! rtpbin udpsrc_rtcp ! rtpbin ! rtpmpadepay ! mpegaudioparse ! mad ! audioconvert ! alsasink</div><div style=""><br></div><div style="">Kind regards</div><div style="">JB</div><div style=""> </div><div style=""><br></div></div><div style=""><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-07-10 20:41 GMT+02:00 Sebastian Dröge <span dir="ltr"><<a href="mailto:sebastian@centricular.com" target="_blank">sebastian@centricular.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fr, 2016-07-08 at 17:37 +0200, Johannes Bauer wrote:<br>
> Hello!<br>
><br>
</span><span class="">> Thanks for your reply!<br>
> Your talk is really informative and i think I understood a lot of<br>
> those parameters much better now.<br>
><br>
> In my understanding I need to distribute a common GstClock in order<br>
> to have the clients synchronised.<br>
><br>
> As I understand, the gst_net_clock needs to be requested by every<br>
> client and cannot be received via multicast.<br>
> So there is a lot of network traffic if every clients request clock<br>
> info from the server.<br>
> Is there a way to distribute the clock via multicast?<br>
<br>
</span>You could use a different protocol :) PTP for example works via<br>
multicast by default, you can use the GStreamer PTP clock on the<br>
clients and use something like ptpd2 on one server.<br>
<br>
Apart from that it all would work the same.<br>
<br>
<br>
Instead of externally distributing the information about which clock to<br>
use, you can also use the RFC7273 mode in gst-rtsp-server and rtspsrc<br>
(or set up the same things via rtpbin). Then this information is also<br>
distributed via the SDP.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
<br>
Sebastian Dröge, Centricular Ltd · <a href="http://www.centricular.com" rel="noreferrer" target="_blank">http://www.centricular.com</a></div></div></blockquote></div><br></div>