GNOME Bugzilla – Bug 746015
alsasrc: busy polling alsa device
Last modified: 2018-11-03 11:35:34 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.
Created attachment 299074 [details] [review]
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.
Review of attachment 299077 [details] [review]:
This commit is simply wrong. The code was not locking recursively, but it was locking different mutex.
alsasrc does not have GST_DELAY_SINK_LOCK like alsasink. I believe that it should be added to alsasrc too.
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.
The busy loop was causing problem in our setup, because we run the pipeline with high priority. It triggered priority inversion.
Comment on attachment 299930 [details] [review]
Reverted this for the time being, seems to have side-effects. Needs more looking into.
(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?
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 :)
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org'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: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/169.