<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.m3605935929418008737attribute-value
{mso-style-name:m_3605935929418008737attribute-value;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>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. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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:<o:p></o:p></p><p class=MsoNormal>gst-launch-1.0 -vm alsasrc device=’dsnoop:CARD=Loopback,DEV=1’ ! deinterleave name=input \<o:p></o:p></p><p class=MsoNormal>audiointerleave name=output ! alsasink device=’hw:CARD=PCH,DEV=0’ sync=false \<o:p></o:p></p><p class=MsoNormal>input.src_0 ! output.sink_0 \<o:p></o:p></p><p class=MsoNormal>input.src_1 ! output.sink_1 \<o:p></o:p></p><p class=MsoNormal>The above pipeline still causes audio glitches/dropouts or freezes. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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:<o:p></o:p></p><p class=MsoNormal>gst-launch-1.0 -vm alsasrc device=’dsnoop:CARD=Loopback,DEV=1’ ! deinterleave name=input \<o:p></o:p></p><p class=MsoNormal>audiointerleave name=output latency=100000000 ! alsasink device=’hw:CARD=PCH,DEV=0’ \<o:p></o:p></p><p class=MsoNormal>input.src_0 ! output.sink_0 \<o:p></o:p></p><p class=MsoNormal>input.src_1 ! output.sink_1 \<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>-Charlie<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b>From:</b> gstreamer-devel <gstreamer-devel-bounces@lists.freedesktop.org> <b>On Behalf Of </b>Nicolas Dufresne<br><b>Sent:</b> Saturday, March 3, 2018 11:28 AM<br><b>To:</b> Discussion of the development of and with GStreamer <gstreamer-devel@lists.freedesktop.org><br><b>Subject:</b> Re: why does alsasink sync=false fix audio problems?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div></div></body></html>