<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le dim. 28 nov. 2021 05 h 30, Ian Steele via gstreamer-devel <<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:16px"><div><div>Thanks for the information. I did run the system overnight. it was still running</div><div dir="ltr">this morning. Maybe it drifted then glitched but it was difficult to tell.</div><div><br></div><div>At them moment I don't have separate code to force the clock.</div></div><div dir="ltr">The objective with this system is to make a command line that builds a </div><div dir="ltr">pipeline that can provided sync playback without separate hardware clocking sample rate converter chips etc..</div><div dir="ltr"><br></div><div dir="ltr">I did note there is a command line 'clockselect' option:</div><div dir="ltr"><br></div><div dir="ltr"><b>gst-launch-1.0 clockselect. \( clock-id=realtime.</b> //... etc<br></div><div dir="ltr"><span><br></span></div><div dir="ltr"><span>I have used this on another system when testing avtp (AVB) audio and it worked.</span></div><div dir="ltr">I also see that clock-id can be ptp. <br></div><div dir="ltr"><br></div><div dir="ltr">I have tried both methods with this system:</div><div dir="ltr"><span>clock-id=realtime. This causes the reference audio output from the player DAC to have strange gaps in the tone burst</span><br></div><div dir="ltr"><span>after a few minutes. Drift on the receiver is the same, the tone burst plays ok.</span></div><div dir="ltr"><span><br></span></div><div dir="ltr"><span>clock-id=ptp. This takes 5 seconds for the pipeline to start so is of no use.</span><span><br></span></div><div dir="ltr"><span>Drift was slightly less though.</span></div><div dir="ltr"><span><br></span></div><div dir="ltr">I used the 'clock select' option on both the player and receiver.</div><div dir="ltr">foe example the receiver:</div><div dir="ltr"><br></div><div dir="ltr"><span><div><b>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 \)</b></div><div dir="ltr"><br></div><div dir="ltr">The clock sync works like this - I have a 3rd system that just generates a master ptp clock to the player and receiver.</div><div dir="ltr">so on those devices the clocking should be:</div><div dir="ltr">ptp --->system clock---->alsa clock</div><div dir="ltr"></div></span></div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:16px"><div dir="ltr"><span><div dir="ltr"><br></div></span></div>
<div><br></div><div dir="ltr">So the question is, can a Gstreamer network RTP audio player and receiver be synched only in software?</div><div dir="ltr"><br></div><div dir="ltr">Thanks again.</div><div dir="ltr"><br></div>
</div><div id="m_2291710501521304043ydpaa6c1f90yahoo_quoted_8797710848">
<div style="font-family:'Helvetica Neue',Helvetica,Arial,sans-serif;font-size:13px;color:#26282a">
<div>
On Sunday, 28 November 2021, 00:33:21 GMT, Nicolas Dufresne via gstreamer-devel <<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank" rel="noreferrer">gstreamer-devel@lists.freedesktop.org</a>> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div id="m_2291710501521304043ydpaa6c1f90yiv5465603578"><div><div><div><br clear="none"><br clear="none"><div><div dir="ltr">Le sam. 27 nov. 2021 17 h 45, Ian Steele via gstreamer-devel <<a shape="rect" href="mailto:gstreamer-devel@lists.freedesktop.org" rel="nofollow noreferrer" target="_blank">gstreamer-devel@lists.freedesktop.org</a>> a écrit :<br clear="none"></div><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:16px"><div dir="ltr">I've been trying to solve this issue for several days but just cant fix.</div><div dir="ltr"><br clear="none"></div><div dir="ltr">I have 2 Raspberry pi CM4 systems (both identical OS) locked together</div><div dir="ltr">with ptp4l. I have got a nice low-latency rtp stream sending 48k 24 bit audio from 1 to another.</div><div dir="ltr"><br clear="none"></div><div dir="ltr">I'm using the audiotestsrc in gstreamer to generate tone bursts so I can look at the signal on my scope from</div><div dir="ltr">each device and see the latency/sync.</div><div dir="ltr"><br clear="none"></div><div dir="ltr">The commands below seem to work well - no glitches and very low latency(approx 8 mS)</div><div dir="ltr"><br clear="none"></div><div dir="ltr">But on the receiver the latency gradually increases. It seems to go up by about 1mS per 3 minutes.</div></div></div></blockquote></div></div><div><br clear="none"></div><div>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.</div><div><br clear="none"></div><div><div><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:16px"><div dir="ltr"><br clear="none"></div><div dir="ltr">TRANSMIT:</div><div dir="ltr"><span></span><div>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</div><div><br clear="none"></div><div dir="ltr">RECEIVE:</div><div dir="ltr"><span></span><div>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</div></div></div><div dir="ltr"><br clear="none"></div><div dir="ltr">Do these look ok?</div><div dir="ltr">Maybe I need to be clocking the receiver from the incoming stream somehow?</div></div></div></blockquote></div></div><div><br clear="none"></div><div>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? </div><div id="m_2291710501521304043ydpaa6c1f90yiv5465603578yqtfd01083"><div><br clear="none"></div><div><div><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:16px"><div dir="ltr"><br clear="none"></div><div dir="ltr">TIA</div><div><br clear="none"></div><div><br clear="none"></div></div></div></blockquote></div></div></div></div><div id="m_2291710501521304043ydpaa6c1f90yiv5465603578yqtfd40910">
</div></div></div></div>
</div>
</div></div></blockquote></div></div></div>