After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 746015 - alsasrc: busy polling alsa device
alsasrc: busy polling alsa device
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2015-03-11 08:54 UTC by Branislav Katreniak
Modified: 2018-11-03 11:35 UTC
See Also:
GNOME target: ---
GNOME version: ---

0007-alsasrc-fix-busy-polling.patch (1.68 KB, patch)
2015-03-11 08:56 UTC, Branislav Katreniak
none Details | Review
0009-alsasink-Remove-recursive-lock-around-snd_pcm_writei.patch (910 bytes, patch)
2015-03-11 09:09 UTC, Branislav Katreniak
none Details | Review
0001-alsasrc-lock-calls-to-snd_pcm_delay-with-mutex-as-in.patch (2.64 KB, patch)
2015-03-20 09:16 UTC, Branislav Katreniak
none Details | Review

Description Branislav Katreniak 2015-03-11 08:54:59 UTC
Alsa src operates in non-blocking mode. If no data are queued in alsa device,
method snd_pcm_readi returns immediately and it is called again and again
in a busy loop until data are available in alsa device.
Comment 1 Branislav Katreniak 2015-03-11 08:56:27 UTC
Created attachment 299074 [details] [review]
Comment 2 Branislav Katreniak 2015-03-11 09:09:28 UTC
Created attachment 299077 [details] [review]

Cleanup locking in the same code in alsasink. With this patch the code structure in alsasrc and alsasink is the same.
Comment 3 Branislav Katreniak 2015-03-13 09:03:01 UTC
Review of attachment 299077 [details] [review]:

This commit is simply wrong. The code was not locking recursively, but it was locking different mutex.
Comment 4 Branislav Katreniak 2015-03-13 13:34:54 UTC
alsasrc does not have GST_DELAY_SINK_LOCK like alsasink. I believe that it should be added to alsasrc too.
Comment 5 Branislav Katreniak 2015-03-20 09:16:54 UTC
Created attachment 299930 [details] [review]

Alsasrc introduced delay_lock in commit 519f85a43e73efb8f3fb2c7be45226e
because alsa-lib is not thread safe for the same handle.
Alsasrc uses the same threading pattern, it should be locked too.
Comment 6 Branislav Katreniak 2015-03-25 15:07:57 UTC
The busy loop was causing problem in our setup, because we run the pipeline with high priority. It triggered priority inversion.
Comment 7 Tim-Philipp Müller 2018-03-07 18:52:17 UTC
Comment on attachment 299930 [details] [review]

Reverted this for the time being, seems to have side-effects. Needs more looking into.
Comment 8 GstBlub 2018-03-07 20:29:51 UTC
(In reply to Tim-Philipp Müller from comment #7)
> Reverted this for the time being, seems to have side-effects. Needs more
> looking into.
What side-effects led you to revert this?
Comment 9 Tim-Philipp Müller 2018-03-07 21:55:36 UTC
I got 'couldn't capture samples fast enough' warnings frequently, and someone else on IRC also complained about this and called it dodgy, so it seemed better to revert and try again next cycle :)
Comment 10 GStreamer system administrator 2018-11-03 11:35:34 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: