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 614545 - gstalsasrc mixer task spins 100% CPU when USB sound card is removed
gstalsasrc mixer task spins 100% CPU when USB sound card is removed
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.10.28
Other Linux
: Normal normal
: 0.10.29
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 507527 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-04-01 08:01 UTC by sam.revitch
Modified: 2010-10-03 11:31 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description sam.revitch 2010-04-01 08:01:00 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.
Comment 1 Sebastian Dröge (slomo) 2010-04-04 19:02:23 UTC
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...
Comment 2 Sebastian Dröge (slomo) 2010-04-04 19:19:40 UTC
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.
Comment 3 Sebastian Dröge (slomo) 2010-10-03 11:31:30 UTC
*** Bug 507527 has been marked as a duplicate of this bug. ***