why does alsasink sync=false fix audio problems?

[Charlie Laub]

CONTENTS DELETED

The author has deleted this message.

[Nicolas Dufresne-5]

Le 3 mars 2018 10:27, "Charlie Laub" <[hidden email]> a écrit :

I am doing some testing with gst-launch (Gstreamer v1.10.4). It’s a simple pipeline that does the following:

Another application sends audio to the ALSA loopback device

Gstreamer uses the output of the loopback as input

The pipeline sends the audio an ALSA sink, a DAC, so I can monitor the audio

 

The pipeline is:

gst-launch-1.0 -vm alsasrc device=’hw:CARD=Loopback,DEV=1’ ! queue ! audioconvert ! audio/x-raw,channels=2,format=S16LE,rate=48000 ! alsasink device=’hw:CARD=PCH,DEV=0’

 

This works perfectly, but:

When I replace “hw” with “dsnoop” in the alsasrc the audio is either stuttering, or stops after a fraction of a second.

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.

 

No errors are produced (that I can see with -vm).

 

For those who are not familiar with it, dsnoop is an ALSA output device that permits multiple “listeners” to connect to it. I use dsnoop so I can connect multiple gstreamer pipelines to an audio stream generated by another application that sends its output to the ALSA loopback.

 

I find this very strange because I have been using (for more than a year) a complicated pipeline that takes the EXACT same audio via dsnoop as the input to the pipeline, but then streams it via RTP/UDP. I never encountered a problem with that application, it’s only with the simple pipeline I show above that I am experiencing this problem.

 

Later I found this thread:

https://e2e.ti.com/support/embedded/linux/f/354/p/569574/2087898

Near the bottom there is a post dated Jan 24, 2017 12:22 PM. The user could only get his similar short alsasrcàalsasink pipeline working if sync=false was set on the sink. I tried this and it worked! The pipeline with dsnoop now plays without error and audio is perfect.

 

Why does adding sync=false fix the problem?

In general, when should I set sync=false on an alsasink?

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Charlie Laub]

CONTENTS DELETED

The author has deleted this message.

[Nicolas Dufresne-5]

Thanks for sharing, excellent point about first synching element latency setting.

Le 4 mars 2018 14:11, "Charlie Laub" <[hidden email]> a écrit :

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 <[hidden email]> On Behalf Of Nicolas Dufresne
Sent: Saturday, March 3, 2018 11:28 AM
To: Discussion of the development of and with GStreamer <[hidden email]>
Subject: Re: why does alsasink sync=false fix audio problems?

 

 

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.

 

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel