Bug#839692: pulseaudio: alsa application uses up 100% cpu when pulse dies

[Felipe Sateler]

On 3 October 2016 at 20:48, treaki <treaki at treaki.tk> wrote:
> Package: pulseaudio
> Version: 7.1-2~bpo8+1
> Severity: important
>
> hi,
>
> just try following to reproduce the problem, happended here manny times:
>
> start an alsamixer so that it access pulseaudio, keep it running, maybe forgett that its still running, and keep your system running. Then eventually pulseaudio will have a problem crash and be restarted imidiatly, normaly you wount recognise, only if you here that or if there is a programm like mumble which dosnt manage to aoutomaticly reconnect to the new instance of pulse.
>
> Than come back to your system, look at the system monitor and wounder why cpu load is that high, open htop, or something similiar, and see that that alsa using application, alsamixer, is using up every cpu it can with one thread (100%). You kill it then of cause but you think that it could act much better.
>
> This force overloading of a shared lib of an alsa application to force it to use pulse even if it is not designed to seames in generall very proplematic. Manny applications (mostly that one which are not only playing sound but doing a bit more with the expected interface to alsa (which dosnt exist as espected)) dont act right with it at all...
>
> So first of all: please fix the problem with that client side alsa2pulse implementation which happens when pulse dies,

This plugin is shipped by libasound2-plugins. pulseaudio merely
enables it when it is running.

It would be interesting to see which part is looping, if the pulse
plugin, the pulse library, or the application. Could you try to
reproduce, and when the app is looping, attach a debugger and get a
backtrace (actually, better if there are a few of these)? Please
remember to install debugging symbols before or the stack traces will
be meaningless.

> and secoundly: why dont create a kernel module which implements the full alsa interface to a real virtual soundcard which is working with all old alsa applications without injecting them just by being a "real" card in /dev/snd/ and not only a ghost that is not realy existing and only working through hidden influences on that process trying to use it by injecting them...

This is a lot of work for very little gain. The current plugin works
via the existing alsa plugin infrastructure, and appears to the
application as just another alsa device.

-- 

Saludos,
Felipe Sateler