[alsa-devel] Event flood on USB disconnect
Hi folks, We're seeing a problem when disconnecting USB headsets in PulseAudio. Steps to reproduce are basically: start PulseAudio, plug in USB device, wait for it to suspend (pcm is closed but mixer is not), disconnect. Fairly often, this results in PA getting killed because the polling thread is realtime and exceeds its rlimit. The problem is not limited to one machine or one USB headset, and I'm running kernel 3.0.4
I'm basically seeing a flood of events on the mixer pollfds (goes as high as 4+ million of them). As far as I can tell, they all contain (POLLERR|POLLNVAL). From a preliminary look at the code this seems to be expected on a card disconnect, but I assume not so often.
I'm going to try to handle this by just stopping PA from listening on these fds when I get a (POLLERR|POLLNVAL), but it seems to me that this is a bug in the driver somewhere. Any ideas w.r.t. what might be going wrong or where I should be looking to debug further?
Cheers, Arun
On Sat, 2011-10-01 at 14:19 +0530, Arun Raghavan wrote:
Hi folks, We're seeing a problem when disconnecting USB headsets in PulseAudio. Steps to reproduce are basically: start PulseAudio, plug in USB device, wait for it to suspend (pcm is closed but mixer is not), disconnect. Fairly often, this results in PA getting killed because the polling thread is realtime and exceeds its rlimit. The problem is not limited to
Missed one detail -- I've only seen this happen on the alsa-source thread, not on alsa-sink, but I've only tested with one device which has playback as well as capture.
-- Arun
2011/10/1 Arun Raghavan arun.raghavan@collabora.co.uk:
On Sat, 2011-10-01 at 14:19 +0530, Arun Raghavan wrote:
Hi folks, We're seeing a problem when disconnecting USB headsets in PulseAudio. Steps to reproduce are basically: start PulseAudio, plug in USB device, wait for it to suspend (pcm is closed but mixer is not), disconnect. Fairly often, this results in PA getting killed because the polling thread is realtime and exceeds its rlimit. The problem is not limited to
Missed one detail -- I've only seen this happen on the alsa-source thread, not on alsa-sink, but I've only tested with one device which has playback as well as capture.
-- Arun
Cannot reproduced this issue on ubuntu 11.04 Live CD with Logictech WebCam mic
PA server still keep running and Gnome Sound Preference automatically change the selected "input device" from USB microphone to on-board sound card when usb webcam is unplugged
Actully Gnome Sound Preference is lying about "no application is using the sound card" since it open the "monitor" at 25Hz (peak-detect" for displaying the vumeter of the microphone
On Tue, 2011-10-04 at 10:30 +0800, Raymond Yau wrote:
2011/10/1 Arun Raghavan arun.raghavan@collabora.co.uk:
On Sat, 2011-10-01 at 14:19 +0530, Arun Raghavan wrote:
Hi folks, We're seeing a problem when disconnecting USB headsets in PulseAudio. Steps to reproduce are basically: start PulseAudio, plug in USB device, wait for it to suspend (pcm is closed but mixer is not), disconnect. Fairly often, this results in PA getting killed because the polling thread is realtime and exceeds its rlimit. The problem is not limited to
Missed one detail -- I've only seen this happen on the alsa-source thread, not on alsa-sink, but I've only tested with one device which has playback as well as capture.
-- Arun
Cannot reproduced this issue on ubuntu 11.04 Live CD with Logictech WebCam mic
Thanks for trying this out.
PA server still keep running and Gnome Sound Preference automatically change the selected "input device" from USB microphone to on-board sound card when usb webcam is unplugged
Actully Gnome Sound Preference is lying about "no application is using the sound card" since it open the "monitor" at 25Hz (peak-detect" for displaying the vumeter of the microphone
Sorry, my bad for not noticing this -- the code that polls the mixer fds got added in PulseAudio 1.0,. Ubuntu 11.04 runs PA 0.9.23. Could you try with an updated PA (and just to make sure, without the GNOME Sound Preferences dialog open, since that'll keep the device open and the disconnect gets handled earlier while polling the pcm).
Cheers, Arun
'Twas brillig, and Arun Raghavan at 01/10/11 09:49 did gyre and gimble:
I'm going to try to handle this by just stopping PA from listening on these fds when I get a (POLLERR|POLLNVAL), but it seems to me that this is a bug in the driver somewhere. Any ideas w.r.t. what might be going wrong or where I should be looking to debug further?
Also a question to ask. Would a POLLERR|POLLNVAL be received any time when normal operations will continue afterwards? e.g. should we use this error as an indicator to ignore it forever or, e.g., just for a finite period of time like 1s.
Although if the underlying cause of the flood of errors can be addressed, that would be nicer!
Col
Colin Guthrie wrote:
Would a POLLERR|POLLNVAL be received any time when normal operations will continue afterwards? e.g. should we use this error as an indicator to ignore it forever or, e.g., just for a finite period of time like 1s.
POLLERR means that the PCM device is in a state where it cannot transfer data. This typically happens on an xrun or when the device is unplugged, if the first system call after that event is poll() and not write(). The error handling should be the same (snd_pcm_prepare(), which might fail).
A disconnected device returns POLLERR|POLLNVAL, while any other error state returns POLLOUT|POLLERR.
Regards, Clemens
participants (4)
-
Arun Raghavan -
Clemens Ladisch -
Colin Guthrie -
Raymond Yau