GNOME Bugzilla – Bug 614545
gstalsasrc mixer task spins 100% CPU when USB sound card is removed
Last modified: 2010-10-03 11:31:30 UTC
I'm trying to use GStreamer 0.10.28 to play audio from a USB FM radio to the desktop sound card. The FM radio provides a USB audio class interface supported by the ALSA snd-usb-audio driver. I can use the following command to set up a pipeline to listen to the radio: gst-launch-0.10 alsasrc device="plughw:1" \! audioconvert \! alsasink Unfortunately, if the sound card is unplugged while such a pipeline is running, attempts to stop the pipeline will generate the following type of console message: ** (gst-launch-0.10:15447): CRITICAL **: Resources for ring buffer 0x16ec1b0 still acquired If this is done from an application which remains running after the pipeline is stopped, it will be left with a thread spinning at 100% CPU. It would appear that the ring buffer is not being released because the alsasrc plugin's gst_alsasrc_unprepare() function is returning failure. This is apparently caused by ENODEV errors from snd_pcm_drop() and snd_pcm_hw_free(), which it may benefit from ignoring. Secondarily, the task_monitor_alsa() task function is calling poll() on a file descriptor that has become bad, and poll() isn't waiting. The task is not being shut down because the ring buffer release failed, and the task function contains no logic to throttle itself or shut itself down in this case, so it spins at 100% CPU.
This should fix the second issue: commit 1e8f3f768953cf4a4eeaab2fd76409f61d9f0009 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Sun Apr 4 20:55:02 2010 +0200 alsamixer: Detect errors from device polling, stop the task and post an error message Partially fixes bug #614545. For the first issue in unprepare, the same is also the case in alsasink. Not sure which errors should be ignored in unprepare and which not...
commit 44e474f76d5fbcf94080e4fa0b95bf0dbd25edd3 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Sun Apr 4 21:18:04 2010 +0200 alsa: Ignore errors when unpreparing or closing the device Errors could happen here when the device was removed already or when something is broken anyway. If errors happen here and they're propagated, the element can't shutdown cleanly. Fixes bug #614545.
*** Bug 507527 has been marked as a duplicate of this bug. ***