gStreamer does not negotiate the requested ALSA buffer and latency times

Hello team,

We are facing an issue related to audio codec. Please find the description as below:

Capture latency-time is longer than expected
$ gst-launch-1.0 -v alsasrc device=plughw:0,0 device=plughw:0,0 buffer-time=200000 latency-time=10000 ! fakesink

Setting pipeline to PAUSED …
Pipeline is live and does not need PREROLL …
Setting pipeline to PLAYING …
New clock: GstAudioSrcClock
/GstPipeline:pipeline0/GstAlsaSrc:alsasrc0: actual-buffer-time = 85306
/GstPipeline:pipeline0/GstAlsaSrc:alsasrc0: actual-latency-time = 42653

Expected results:

/GstPipeline:pipeline0/GstAlsaSrc:alsasrc0: actual-buffer-time = 200000
/GstPipeline:pipeline0/GstAlsaSrc:alsasrc0: actual-latency-time = 10000

The latency-time is expected to be less than or equal 10k, but it is around 42k.
Please help us here.

Regards,
Arjun

I believe this is the observed behavior is expected.

gstreamer will negotiate with the audio driver to select the closest supported period and buffer size. The driver supports only a limited set of known working values.

There are ways to relax the limitation but there are also comments on the forum that report problems when doing so you will need to test any changes you choose to adopt very carefully.

1 Like

Hello @srini,

We have tried the solution provided by you but we are not getting exact 10k latency time, logs for the same as followed:

root@linaro-alip:~# gst-launch-1.0 -v alsasrc device=plughw:0,0 device=plughw:0,0 buffer-time=200000 latency-time=10000 ! fakesink
Setting pipeline to PAUSED …
Pipeline is live and does not need PREROLL …
Setting pipeline to PLAYING …
New clock: GstAudioSrcClock
/GstPipeline:pipeline0/GstAlsaSrc:alsasrc0: actual-buffer-time = 85260
/GstPipeline:pipeline0/GstAlsaSrc:alsasrc0: actual-latency-time = 10657
Redistribute latency…
/GstPipeline:pipeline0/GstAlsaSrc:alsasrc0.GstPad:src: caps = audio/x-raw, format=(string)S16LE, layout=(string)interleaved, rate=(int)44100, channels=(int)2, channel-m3
/GstPipeline:pipeline0/GstFakeSink:fakesink0.GstPad:sink: caps = audio/x-raw, format=(string)S16LE, layout=(string)interleaved, rate=(int)44100, channels=(int)2, channe3
^Chandling interrupt.
Interrupt: Stopping pipeline …
Execution ended after 0:00:10.135364215
Setting pipeline to PAUSED …
Setting pipeline to READY …
Setting pipeline to NULL …
Freeing pipeline …

In our application code there are algorithms that expect to receive chunks in exactly 10000 size. To fix it on our side we need to change some critical areas in code that will have a big implication.

So the gstreamer pipeline should work exactly according to configurations.

Also we see that there is a similar latency configuration for alsasink that also does not work. Currently alsasink adds a big latency that we want to reduce.

These configurations work without any issues on any laptop.

Please help to solve this.

Regards,
Parth Y Shah

Hi Arjun,
For pulseaudio we switch off the time based scheduling on Qcom Upstream platforms.
Can you update /etc/pulse/default.pa with below line just after “.ifexists module-udev-detect.so”
load-module module-udev-detect tsched=0

Thanks,
srini

Hi @srini,

We have done below change as suggested,

But there is no change in result.

Can you please help further?

Regards,
Parth Y Shah

Hello @srini,

Any update here?

Regards,
Parth Y Shah

Hi @srini,

Any updates here?

Regards,
Parth Y Shah

@arjun.salariya, I think this specific problem could require some advanced investigation, so not sure the community forum is the most efficient path here.