Event flood on USB disconnect

Event flood on USB disconnect

[Arun Raghavan]

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

Re: Event flood on USB disconnect

[Arun Raghavan]

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

Re: Event flood on USB disconnect

[Colin Guthrie]

'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
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

Re: Event flood on USB disconnect

[Clemens Ladisch]

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

Re: Event flood on USB disconnect

[Raymond Yau]

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

Re: Event flood on USB disconnect

[Arun Raghavan]

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