<div dir="auto"><div>Thanks for sharing, excellent point about first synching element latency setting. <div class="gmail_extra"> <div class="gmail_quote">Le 4 mars 2018 14:11, "Charlie Laub" <<a href="mailto:charleslaub@sbcglobal.net">charleslaub@sbcglobal.net</a>> a écrit : <blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-7151355045028895151WordSection1">Nicolas, thank you for your reply. I discovered another solution to the dsnoop audio glitch problem that I wanted to share because it illuminates the magnitude of the dsnoop latency. I am using a pipeline that includes deinterleave and later audiointerleave so that I can access and modify the audio in individual channels. A simplistic example is this pipeline:gst-launch-1.0 -vm alsasrc device=’dsnoop:CARD=Loopback,DEV=1’ ! deinterleave name=input \audiointerleave name=output ! alsasink device=’hw:CARD=PCH,DEV=0’ sync=false \input.src_0 ! output.sink_0 \input.src_1 ! output.sink_1 \The above pipeline still causes audio glitches/dropouts or freezes. The element audiointerleave has its own latency property that is used to accommodate various delays in the streams that are sinked to it. I found that if I set audiointerleave’s latency to 100 milliseconds (100000000) even when sync=true (the default of the sync property) the audio was also rendered without problems. The pipeline looks like this:gst-launch-1.0 -vm alsasrc device=’dsnoop:CARD=Loopback,DEV=1’ ! deinterleave name=input \audiointerleave name=output latency=100000000 ! alsasink device=’hw:CARD=PCH,DEV=0’ \input.src_0 ! output.sink_0 \input.src_1 ! output.sink_1 \ My guess is that the additional latency of dsnoop is accommodated by the audiointerleave latency, meaning the dsnoop latency is between 10 and 100 milliseconds. Without increasing the audiointerleave latency, even when I set sync=false I was still experiencing stuttering audio. It seems that the first element in the pipeline that checks timing of buffers with respect to the pipeline clock and can drop buffers that are “too late” must have its parameters adjusted so that the dsnoop latency can be accommodated. -Charlie From: gstreamer-devel <<a href="mailto:gstreamer-devel-bounces@lists.freedesktop.org" target="_blank">gstreamer-devel-bounces@lists.freedesktop.org</a>> On Behalf Of Nicolas Dufresne Sent: Saturday, March 3, 2018 11:28 AM To: Discussion of the development of and with GStreamer <<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a>> Subject: Re: why does alsasink sync=false fix audio problems?<div class="quoted-text"> <div><div> </div><div>Just like most alsa plugin, dsnoop does not broadcast the extra latency it is adding. As a side effect, all samples are submitted late and are dropped. Disabling the sync turns GST into a dummy audio filler. There is various settings you can play with that will improve this situation, have a look at latency and buffer-time on alsasrc/sink.</div><div> </div></div></div></div></div> _______________________________________________ gstreamer-devel mailing list <a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> </blockquote></div> </div></div></div>