stream drifting out of sync

[Ian Steele]

Thanks for the information. I did run the system overnight. it was still runningthis 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 
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 togetherwith 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  fromeach 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/4a01b65e/attachment-0001.htm>