100% CPU usage on default microphone input switching.

[rwchateau]

(Please use the mailing list for support requests and general discussion. This is only for actual bugs.)

Describe the bug We noticed that when we switched the default input via the ubuntu settings our application would spike to 100% cpu usage and stay there.

To Reproduce Our applicatition opens on startup a stream both with the Default Input and Output device. When switching the default microphone of the system based on Ubuntu 22.04 the application would spike to 100% CPU usages and stay there. We needed to restart the application to fix the problem. It also happend when disconnecting a bluetooth headset, that was the only input device, therefor having no input device, then connecting it again and selecting that as the default input again.

Expected behavior The same CPU usage after switching the default input device as before switching it.

Desktop (please complete the following information):

• OS: Ubuntu desktop
• OS Version 22.04
• PortAudio version: stable, nightly snapshot (which?), current (please give date and/or Git hash):
• If Windows or Linux, which Host API (e.g. WASAPI): Alsa with Pulseaudio

Additional context Add any other context about the problem here.

[RossBencina]

Are you able to localise the problem to ALSA or PortAudio using a profiler? or just drop in with a debugger and see where it is stuck.

[rwchateau]

Hi RossBencina,

A couple of days after making this issue we replaced pulseaudio with pipewire/wireplumber on the affected systems and were unable to reproduce the problem. Time was limited and because of some other problems we kept the pipewire/wireplumber setup.

I will try to make some time at the end of this or beginning of next week to do some profiling.

[rouseabout]

I experience this problem too when using PortAudio ALSA to connect to a duplex portaudio server.

Steps to reproduce:

1. Open duplex stream using ASLA hostapi on 'default' device (pulseaudio backend).
2. Enable a new input device in pulseaudio, either using pavucontrol, or plugging in USB DAC.
3. Watch CPU utilisation of the portaudio process climb to 100%.
4. The portaudio interrupt is still serviced, but there is noticible delay, depending on what other device was enabled/plugged in.

Tested on Debian.

Debugging:

I have tried to instrument libportaudio to understand the cause of the high CPU load. It appears there is a busy loop that goes something like this:

• CallbackThreadFunc calls PaAlsaStream_WaitForFrames()

  • PaAlsaStream_WaitForFrames() has a while (pollPlayback || pollCapture) loop.

  • The action of plugging in a new device, causes: the delay returned by the playback device to be very large [pa_linux_alsa.c:3388]. snd_pcm_poll_descriptors_revents() of the playback device to return 0 most of the time [3726]

  • On the first iteration of the while loop, the playback is (often) not successfully polled, but capture is. This results in call to ContinuePoll() [3952]. The large delay triggers the margin < 0 condition in ContinuePoll() [3407] and forces pollPlayback to stop. Because the playback device was never successfully polled, self->playback.ready = 0.

  • Because self->playback.ready == 0, the "drop input" block [3970] is triggered. PortAudio drops input, sets return *framesAvail = 0 and sets self->capture.ready = 0. However dropping input doesn't seem to help recover the playback delay.

• Because PaAlsaStream_WaitForFrames() returns framesAvail==0, the CallbackThreadFunc loop has nothing to do. Goto beginning.

[rouseabout]

Switching to pipewire and the issue goes away.