Hi, I have been wrong in at least one part of my previous update to this bug. Even if I stop all threads in the sound application (in my case baresip) in the debugger, pulseaudio still run's at 100% CPU spamming syslog. Only killing baresip (probably the closing of file descriptors) makes pulseaudio recover.
I got confused, because somehow this situation causes an other thread of baresip consume lot's of CPU, which made me believe that there is a rather tight loop between baresip and pulseaudio. Actually the calls to the sound API never return while pulseaudio is busy, thus the application never get's an error and can't actually close its ALSA handles. So at this point I'm convinced the entire problem is within pulseaudio. Since baresip is not a pulseaudio but an ALSA application, works fine without pulseaudio installed and only uses pulseaudio because pulseaudio makes itself the default ALSA device on installation, I think it is fair to say that pulseaudio is breaking unrelated software here. I'm tempted to raise the severity of this bug to release critical, but I guess this should be at the discretion of the maintainers. This is clearly a (probably rather old) upstream bug. It seems to mostly manifest itself with SoC devices, which might explain why it is more often seen recently and with debian: Debian arm ports are quite popular with users of SoC based laptops. >From the debian packaging PoV I can see two possible workarounds: * Disable sample rate switching by setting defaut-sample-rate and alternate-sample-rate to the same value by default for the ARM based ports and prominently document the problem for everybody else. * Don't enable pulseaudio at all on ARM based ports without some kind of manual intervention by the local admin. HTH, Harald -- Es gibt viele Maßnahmen gegen die Klimakrise, die leicht und ohne Verlierer umsetzbar sind. Das Problem ist immer noch das Desinteresse der etablierten Parteien. https://haraldgeyer.at/Klimaschutz.html
