<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le sam. 17 oct. 2020 13 h 00,  <<a href="mailto:charleslaub@sbcglobal.net">charleslaub@sbcglobal.net</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>Perhaps you didn't notice the default slave-method, which is skew. Skew will remove or fill with silence the audio stream to fix the synchronization >between the audio card clock and the NTP clock. As it does that naively, you will ear ticks and pop. You'll also notice the resample method, which in >theory should work, but in practice the resampler there is buggy and the adjustment too aggressive. Some work is needed there to make it work.<br>
<br>
As you say "buggy" is an understatement - it is TERRIBLE. It's essentially unlistenable because the "over aggressive" action introduces a warble to the music, like you are listening underwater.  <br>
<br>
So, the only solution that comes to mind is custom slaving, which is not available to the general public? Hmmmm.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Would be nice to tone down a little. The code is open source, the hard work of plumbing this is in place, but no one felt like contributing a fix for this (resampling is expensive, so mostly for desktop, were audio deamon already do a much better job). And we are aware it never worked.</div><div dir="auto"><br></div><div dir="auto">As for the custom slaving mode, it's publicly available, but you need audio HW with a controllable PLL, and the rounding + smoothing in such case will always be HW specific.</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">
<br>
Perhaps in place of the buggy ALSA resampler, you could implement asynchronous resampling? This was </blockquote></div></div><div dir="auto"><br></div><div dir="auto">This is pure C, there is no ALSA there. It is about 50 line of code. We have another resampler now, but no one looked it up to see if it can be used more dynamicly then how it is used in audioresample element.</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">brought up in a post a couple of days ago in this list under the subject "Adaptive resampling in gstaudiobasesink.c". I think it would be very worthwhile and would really improve the audio performance of Gstreamer in general.<br>
<br>
Could you or someone follow up on that topic? <br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I'm sorry, I don't remember this thread. Do you have links ? Perhaps a merge request would get more attention.</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">
<br>
-Charlie<br>
<br>
-----Original Message-----<br>
From: gstreamer-devel <<a href="mailto:gstreamer-devel-bounces@lists.freedesktop.org" target="_blank" rel="noreferrer">gstreamer-devel-bounces@lists.freedesktop.org</a>> On Behalf Of Nicolas Dufresne<br>
Sent: Saturday, October 17, 2020 10:50 AM<br>
To: Discussion of the development of and with GStreamer <<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank" rel="noreferrer">gstreamer-devel@lists.freedesktop.org</a>><br>
Subject: Re: rtpbin: ts adjustment needs filtering/smoothing<br>
<br>
Perhaps you didn't notice the default slave-method, which is skew. Skew will remove or fill with silence the audio stream to fix the synchronization between the audio card clock and the NTP clock. As it does that naively, you will ear ticks and pop. You'll also notice the resample method, which in theory should work, but in practice the resampler there is buggy and the adjustment too aggressive. Some work is needed there to make it work.<br>
<br>
Well known companies using GStreamer have introduced the "custom"<br>
slave-method. Along with<br>
gst_audio_base_sink_set_custom_slaving_callback(), you get notified per units of the drift. These vendor controlls the HW, so instead of resampling, they will adjust the audio clock PLL in order to lock the audio to the system/ntp/ptp/etc. clock in use.<br>
>  <br>
> I would be happy to provide my pipelines if that would be helpful, <br>
> provide measurement data, or any other info that might lead to a <br>
> solution.<br>
>  <br>
> -Charlie<br>
>  <br>
> _______________________________________________<br>
> gstreamer-devel mailing list<br>
> <a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank" rel="noreferrer">gstreamer-devel@lists.freedesktop.org</a><br>
> <a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank" rel="noreferrer">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank" rel="noreferrer">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</blockquote></div></div></div>