Cork silent audio streams to reduce CPU usage in dom0

[Rudd-O]

Hi! libvirtd and qubes-manager are constantly hogging CPU (not too much, but some), and pulseaudio does that too.

For the libvirtd + qubes-manager thing -- doesn't it make sense to query libvirtd only when an event has taken place instead of periodically? Running qubes-manager destroys battery life as it is right now (5 watts estimate, thousands of wakeups from both processes).

For pulseaudio -- is it really necessary for pulseaudio to consume CPU when nothing is going on audio-wise? On a normal desktop, this doesn't happen.

[marmarek]

I think the libvirtd + qubes-manager is dupplicate of #1253
As for pulseaudio, it is probably because audio stream isn't (currently) properly suspended when not used. Previously pulseaudio automatically suspended inactive devices, but now, for some reason it doesn't. Maybe some configuration option or so? See #1322 for some details about that.

[marmarek]

I think the libvirtd + qubes-manager is dupplicate of #1253
As for pulseaudio, it is probably because audio stream isn't (currently) properly suspended when not used. Previously pulseaudio automatically suspended inactive devices, but now, for some reason it doesn't. Maybe some configuration option or so? See #1322 for some details about that.

[Rudd-O]

paman doesn't tell me which streams are suspended (there's one playback stream and one record stream per running VM).

pactl list sink-inputs shows every stream is NOT corked, which is not what I would expect if the VMs aren't running any audio. Essentially the stream associated with each VM keeps playing "silent audio".

module-suspend-on-idle is clearly loaded, but if there are several streams playing audio, how can the device ever suspend?

[Rudd-O]

paman doesn't tell me which streams are suspended (there's one playback stream and one record stream per running VM).

pactl list sink-inputs shows every stream is NOT corked, which is not what I would expect if the VMs aren't running any audio. Essentially the stream associated with each VM keeps playing "silent audio".

module-suspend-on-idle is clearly loaded, but if there are several streams playing audio, how can the device ever suspend?

[marmarek]

pactl list sink-inputs shows every stream is NOT corked, which is not what I would expect if the VMs aren't running any audio. Essentially the stream associated with each VM keeps playing "silent audio".

This is exactly what I said about (lack of) stream suspending. Actually those streams aren't playing "silent audio", but are not providing the samples (so it looks like buffer underrun from pulseaudio POV).

[marmarek]

pactl list sink-inputs shows every stream is NOT corked, which is not what I would expect if the VMs aren't running any audio. Essentially the stream associated with each VM keeps playing "silent audio".

This is exactly what I said about (lack of) stream suspending. Actually those streams aren't playing "silent audio", but are not providing the samples (so it looks like buffer underrun from pulseaudio POV).

[Rudd-O]

What the client should do is, when there are no streams on the other side, they should suspend their own output explicitly on dom0. Same on the VM side -- if there's nothing playing, then the "device" should suspend, and of course that suspension should carry over the vchan to dom0 for the module on dom0 to suspend.

[Rudd-O]

What the client should do is, when there are no streams on the other side, they should suspend their own output explicitly on dom0. Same on the VM side -- if there's nothing playing, then the "device" should suspend, and of course that suspension should carry over the vchan to dom0 for the module on dom0 to suspend.

[marmarek]

Yes, generally you are right. Currently the missing part is "that suspension should carry over the vchan to dom0" - there is no signaling VM->dom0 to make the protocol as simple as possible (currently it contains only raw samples in predefined format). But one-bit signaling is not something unthinkable. Maybe worth a separate ticket?

Anyway, it wasn't a problem for a long time (device was correctly suspended after underrun detection), so maybe it is all about something else?

[marmarek]

Yes, generally you are right. Currently the missing part is "that suspension should carry over the vchan to dom0" - there is no signaling VM->dom0 to make the protocol as simple as possible (currently it contains only raw samples in predefined format). But one-bit signaling is not something unthinkable. Maybe worth a separate ticket?

Anyway, it wasn't a problem for a long time (device was correctly suspended after underrun detection), so maybe it is all about something else?

[Rudd-O]

Underrun should in principle not be abused to force suspend. Maybe PulseAudio changed to continue "playing back" the "silent buffer" that underruns present to it. If they did so, then their behavior is arguably correct -- the sending side can absolutely continue to send data at any point, thus they need to keep remixing it.

I just powered off all of my VMs. PulseAudio stopped hogging CPU. This points to the vchan clients causing the problem.

[Rudd-O]

Underrun should in principle not be abused to force suspend. Maybe PulseAudio changed to continue "playing back" the "silent buffer" that underruns present to it. If they did so, then their behavior is arguably correct -- the sending side can absolutely continue to send data at any point, thus they need to keep remixing it.

I just powered off all of my VMs. PulseAudio stopped hogging CPU. This points to the vchan clients causing the problem.

[Rudd-O]

Which RPMs should I expect to be updated as a result of this bug fix? Thanks in advance.

[Rudd-O]

Which RPMs should I expect to be updated as a result of this bug fix? Thanks in advance.

[marmarek]

qubes-gui-dom0 and qubes-gui-vm. This will be part of Qubes 3.2.

[marmarek]

qubes-gui-dom0 and qubes-gui-vm. This will be part of Qubes 3.2.