stream drifting out of sync

[Nicolas Dufresne]

Le dim. 28 nov. 2021 05 h 30, Ian Steele via gstreamer-devel <
gstreamer-devel at lists.freedesktop.org> a écrit :

> Thanks for the information. I did run the system overnight. it was still
> running
> this morning. Maybe it drifted then glitched but it was difficult to tell.
>
> At them moment I don't  have separate code to force the clock.
> The objective with this system is to  make a command line that builds a
> pipeline that can provided sync playback without separate hardware
> clocking sample rate converter chips etc..
>
> I did note there is a command line  'clockselect' option:
>
> *gst-launch-1.0 clockselect. \( clock-id=realtime.*  //... etc
>
> I have used this on another system when testing avtp (AVB) audio and it
> worked.
> I also see that clock-id can be ptp.
>
> I have tried both methods with this system:
> clock-id=realtime. This causes the reference audio output from the player
> DAC to have strange gaps in the tone burst
> after a few minutes.  Drift on the receiver is the same, the tone burst
> plays ok.
>
> clock-id=ptp.  This takes 5 seconds for the pipeline to start so is of no
> use.
> Drift was slightly less though.
>
> I used the 'clock select' option on both the player and receiver.
> foe example the receiver:
>
> *gst-launch-1.0  -vv clockselect. \( clock-id=ptp udpsrc
> address=239.255.0.10 port=5004 multicast-iface=eth0 ! application/x-rtp,
> clock-rate=48000, channels=2 ! rtpjitterbuffer latency=5  ! rtpL24depay !
> audiorate  ! audioconvert ! alsasink  processing-deadline=0 latency-time=1
> buffer-time=1 \)*
>
> The clock sync works like this - I have a 3rd system that just generates a
> master ptp clock to the player and receiver.
> so on those devices the clocking should be:
> ptp --->system clock---->alsa clock
>

Ah, so your pipeline should be using the system clock. Try and set
provide-clock=0 the monotonic clock respond to adjtime, so will have the
same slope. Though GST does not do live resampling, if you use pipewire or
puleaudio, they will all drive the audio by the system clock an do
real-time resampling to avoid cuts or gaps.


>
> So the question is, can a Gstreamer network RTP audio player and receiver
> be synched only in software?
>
> Thanks again.
>
> On Sunday, 28 November 2021, 00:33:21 GMT, Nicolas Dufresne via
> gstreamer-devel <gstreamer-devel at lists.freedesktop.org> wrote:
>
>
>
>
> Le sam. 27 nov. 2021 17 h 45, Ian Steele via gstreamer-devel <
> gstreamer-devel at lists.freedesktop.org> a écrit :
>
> I've been trying to solve this issue for several days but just cant fix.
>
> I have 2 Raspberry pi CM4 systems (both identical OS) locked together
> with ptp4l. I have got a nice low-latency rtp stream sending 48k 24 bit
> audio from 1 to another.
>
> I'm using the audiotestsrc in gstreamer to generate tone bursts so I can
> look at the signal on my scope  from
> each device and see the latency/sync.
>
> The commands below seem to work well - no glitches and very low
> latency(approx 8 mS)
>
> But on the receiver the latency gradually increases. It seems to go up by
> about 1mS per  3 minutes.
>
>
> Out of curiosity, have you ran this for over 120m ? Aslasink drift
> tolerance is set at 40ms after which it will skew (insert silence of cut).
> The resampling there have never worked.
>
>
> TRANSMIT:
> gst-launch-1.0 -vv audiotestsrc  is-live=true wave=ticks
> apply-tick-ramp=true tick-interval=100000000 freq=10000 volume=0.5
> sine-periods-per-tick=100  ! audioconvert ! audio/x-raw, format=S24LE,
> rate=48000, channels=2 ! tee name=t ! audioconvert ! queue ! rtpL24pay !
> udpsink host=239.255.0.10 t. ! queue ! alsasink
>
> RECEIVE:
> gst-launch-1.0 udpsrc address=239.255.0.10 port=5004 multicast-iface=eth0
> ! application/x-rtp, clock-rate=48000, channels=2 ! rtpjitterbuffer
> latency=5 ! rtpL24depay ! audioconvert ! alsasink  processing-deadline=0
> latency-time=1 buffer-time=1
>
> Do these look ok?
> Maybe I need to be clocking the receiver from the incoming stream somehow?
>
>
> Looks fine, you can lower the tolerance on the sink perhaps. You have
> mentioned PTP clock, but both pipeline will run off alsasink clock, was
> this just an illustration or you have code to force the clock?
>
>
> TIA
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20211128/3939d2e4/attachment.htm>