Suspend PulseAudio sinks when they are not used #2324

New issue

Closed

opened 2026-02-20 22:04:35 -05:00 by deekerman · 1 comment

deekerman commented

2026-02-20 22:04:35 -05:00

Owner

Originally created by @savchenko on GitHub (Nov 10, 2021).

Describe the bug
Mumble keeps PA sink awake even when client has its microphone and speakers disabled ("deafened and muted").

Steps to Reproduce

Launch pulseaudio -v and observe its output.

Compare, for example, with mpv or your favourite music player. Start playing, then put it on pause:

I: [pulseaudio] module-suspend-on-idle.c: Sink alsa_output.usb-Solid_State_Logic_SSL_2-00.analog-stereo idle for too long, suspending ...
I: [alsa-sink-USB Audio] alsa-sink.c: Device suspended...
I: [pulseaudio] core.c: All sinks and sources are suspended, vacuuming memory

Close the audio player, try the same with Mumble.
Sink stays open:
```
I: [pulseaudio] protocol-native.c: Requested tlength=60.00 ms, minreq=10.00 ms
I: [pulseaudio] protocol-native.c: Final latency 60.00 ms = 20.00 ms + 2*10.00 ms + 20.00 ms
```
This results in an excessive CPU usage and unnecessary memory reservation. Former is (much) more of a problem as for some reason running Mumble makes PA eat ~10% CPU. For comparison, playing audio via mpv is about 0.5-1%.

Expected behavior

Mumble tells PA to pause the processing when it's not needed.
Ideally, PA/Mumble combination consumes (much) less CPU than 10% of 11th gen i5 :)

Screenshots
N/A

Desktop (please complete the following information):

OS: Debian 11, pulseaudio 14.2.
Version: master with https://github.com/mumble-voip/mumble/pull/5307 applied.

Additional context
If https://github.com/mumble-voip/mumble/issues/5300 is fixed, this might be irrelevant (or at least much less relevant). Modern ALSA does all the mixing and resampling by itself.

Originally created by @savchenko on GitHub (Nov 10, 2021). **Describe the bug** Mumble keeps PA sink awake even when client has its microphone and speakers disabled ("deafened and muted"). **Steps to Reproduce** 1. Launch `pulseaudio -v` and observe its output. 2. Compare, for example, with `mpv` or your favourite music player. Start playing, then put it on pause: ``` I: [pulseaudio] module-suspend-on-idle.c: Sink alsa_output.usb-Solid_State_Logic_SSL_2-00.analog-stereo idle for too long, suspending ... I: [alsa-sink-USB Audio] alsa-sink.c: Device suspended... I: [pulseaudio] core.c: All sinks and sources are suspended, vacuuming memory ``` 3. Close the audio player, try the same with Mumble. 4. Sink stays open: ``` I: [pulseaudio] protocol-native.c: Requested tlength=60.00 ms, minreq=10.00 ms I: [pulseaudio] protocol-native.c: Final latency 60.00 ms = 20.00 ms + 2*10.00 ms + 20.00 ms ``` This results in an excessive CPU usage and unnecessary memory reservation. Former is (much) more of a problem as for some reason running Mumble makes PA eat ~10% CPU. For comparison, playing audio via `mpv` is about 0.5-1%. **Expected behavior** 1. Mumble tells PA to pause the processing when it's not needed. 2. Ideally, PA/Mumble combination consumes (much) less CPU than 10% of 11th gen i5 :) **Screenshots** N/A **Desktop (please complete the following information):** - OS: Debian 11, pulseaudio 14.2. - Version: `master` with https://github.com/mumble-voip/mumble/pull/5307 applied. **Additional context** If https://github.com/mumble-voip/mumble/issues/5300 is fixed, this might be irrelevant (or at least _much_ less relevant). Modern ALSA does all the mixing and resampling by itself.

deekerman closed this issue

2026-02-20 22:04:37 -05:00

deekerman commented

2026-02-20 22:04:38 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (Nov 11, 2021):

Related to the high CPU usage: #4177 and #1092

In terms of this request itself: I think this could be a (partial) duplicate of #1089 which was implemented for PulseAudio in #171 but reverted again in #4633, because this has caused quite a few issues due to the way the audio system is currently implemented.

The gist of it is: The audio system needs to be refactored and redesigned before something like this is possible.

Given that we already have #1089 (and the other linked issues), I think this issue here does not really describe a separate issue. Therefore, I'll close this in favor of the other issues.

@Krzmbrzl commented on GitHub (Nov 11, 2021): Related to the high CPU usage: #4177 and #1092 In terms of this request itself: I think this could be a (partial) duplicate of #1089 which was implemented for PulseAudio in #171 but reverted again in #4633, because this has caused quite a few issues due to the way the audio system is currently implemented. The gist of it is: The audio system needs to be refactored and redesigned before something like this is possible. Given that we already have #1089 (and the other linked issues), I think this issue here does not really describe a separate issue. Therefore, I'll close this in favor of the other issues.

deekerman referenced this issue

2026-02-20 22:14:42 -05:00

Proper physical treatment of sound waves for improved spatial audio #2906