synchronising multiple audio clients

[Johannes Bauer]

Hi!

Thank you for your answer!

I ended up using the gst_ntp_clock_new and it works good so far.
Sometimes you hear them drifting apart by a little (I guess about 50ms),
but they are getting in sync again.
Maybe I will try to use a ptp clock source for further improvement, but im
happy with that for the moment.
My problem now is, that i want to have the delay between the mic source and
the remote sinks as small as possible.

So i use

  g_object_set(G_OBJECT(micsrc), "latency-time", (guint64)2000, NULL);
  g_object_set(G_OBJECT(micsrc), "buffer-time", (guint64)20000, NULL);

for my directsoundsrc at the sender and

  g_object_set(G_OBJECT(audiosink), "latency-time", (guint64)2000, NULL);
  g_object_set(G_OBJECT(audiosink), "buffer-time", (guint64)50000, NULL);
  g_object_set(G_OBJECT(rtpbin), "latency", 200, NULL);

for the alsasinks at the remote clients.

The latency at the beginning is ok, with about 300ms, but as long as the
stream is active it increases.
After 24 hours it was about 5 seconds and after 72 hours of live streaming
it was about 25 seconds.

Is there something wrong with my settings here. How can i stop the
increasing latency and further reduce the overall latency of the pipeline?

My pipeline uses following elements:

  directsoundsrc ! audioconvert ! lamemp3enc ! rtpmpapay ! rtpbin !
udpsink_rtp  rtpbin ! udpsink_rtcp

  udpsrc_rtp ! rtpbin udpsrc_rtcp ! rtpbin ! rtpmpadepay ! mpegaudioparse !
mad ! audioconvert ! alsasink

Kind regards
JB




2016-07-10 20:41 GMT+02:00 Sebastian Dröge <sebastian at centricular.com>:

> On Fr, 2016-07-08 at 17:37 +0200, Johannes Bauer wrote:
> > Hello!
> >
> > Thanks for your reply!
> > Your talk is really informative and i think I understood a lot of
> > those parameters much better now.
> >
> > In my understanding I need to distribute a common GstClock in order
> > to have the clients synchronised.
> >
> > As I understand, the gst_net_clock needs to be requested by every
> > client and cannot be received via multicast.
> > So there is a lot of network traffic if every clients request clock
> > info from the server.
> > Is there a way to distribute the clock via multicast?
>
> You could use a different protocol :) PTP for example works via
> multicast by default, you can use the GStreamer PTP clock on the
> clients and use something like ptpd2 on one server.
>
> Apart from that it all would work the same.
>
>
> Instead of externally distributing the information about which clock to
> use, you can also use the RFC7273 mode in gst-rtsp-server and rtspsrc
> (or set up the same things via rtpbin). Then this information is also
> distributed via the SDP.
>
> --
>
> Sebastian Dröge, Centricular Ltd · http://www.centricular.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160714/0af49b69/attachment-0001.html>