Allow user to set qube audio volume

[alimirjamali]

This is the pacat-simple-vchan core part of the patch to introduce a -V volume command line option. It is used by qvm-start-daemon and salt formulas.

resolves: QubesOS/qubes-issues#2724

[marmarek]

(moving discussion from QubesOS/qubes-core-admin-client#405)

How should it be dealt with DispVMs based on whonix-workstation-xx-dvm? Shouldn't they be muted by default?

If something should not have audio at all, setting audiovm to none is the proper way. Nowadays dynamic change of audiovm should work, so if one wishes, they can enable audiovm later too.

For those we do not want to set and we want pulse to remember the previous setting, I could easily adjust pacat-simple-vchan to pass NULL (like before) to pa_stream_connect_playback if audio-volume feature is not set. So the previous volume is preserved.

That still won't work as one would expect. pa_stream_connect_playback is also called when pulseaudio/pipewire is restarted (which may also happen on its own in some cases), and your implementation would reset the volume in such case. And finally, "volume" and "mute" are two separate things. While you can emulate mute with setting volume to 0, it's not the proper way - for example it's annoying to un-mute and have it the same volume as other qubes.

[alimirjamali]

How should it be dealt with DispVMs based on whonix-workstation-xx-dvm? Shouldn't they be muted by default?

If something should not have audio at all, setting audiovm to none is the proper way. Nowadays dynamic change of audiovm should work, so if one wishes, they can enable audiovm later too.

For the DispVMs based on whonix-workstation-xx-dvm, I assumed users may want them to be muted at start rather than having audiovm completely removed? While dynamic set of audiovm for such DispVMs is possible, I guess it is not that convenient?

That still won't work as one would expect. pa_stream_connect_playback is also called when pulseaudio/pipewire is restarted (which may also happen on its own in some cases), and your implementation would reset the volume in such case. And finally, "volume" and "mute" are two separate things. While you can emulate mute with setting volume to 0, it's not the proper way - for example it's annoying to un-mute and have it the same volume as other qubes.

For this issue, I believe I can do it before the g_main_loop_run to avoid resetting the volume in the mentioned cases. And the audio-volume could be dual purpose. An integer value between 0 to 150 to set the volume and a mute string to actually mute rather than setting the volume?

[marmarek]

For the DispVMs based on whonix-workstation-xx-dvm, I assumed users may want them to be muted at start rather than having audiovm completely removed? While dynamic set of audiovm for such DispVMs is possible, I guess it is not that convenient?

True, currently requires CLI, while volume/mute can be changed via standard volume control. Kinda related to QubesOS/qubes-issues#10449

For this issue, I believe I can do it before the g_main_loop_run to avoid resetting the volume in the mentioned cases.

I don't think so, stream objects are not created at this point yet.

And the audio-volume could be dual purpose. An integer value between 0 to 150 to set the volume and a mute string to actually mute rather than setting the volume?

This might be okay (but honestly, I still think using anything other than mute here would lead to issues).

[alimirjamali]

And the audio-volume could be dual purpose. An integer value between 0 to 150 to set the volume and a mute string to actually mute rather than setting the volume?

This might be okay (but honestly, I still think using anything other than mute here would lead to issues).

I amended the patch to implement both volume value and mute option.

That still won't work as one would expect. pa_stream_connect_playback is also called when pulseaudio/pipewire is restarted (which may also happen on its own in some cases), and your implementation would reset the volume in such case

I implemented some measures to set volume or mute only at the first call to pa_stream_connect_playback. I have tested it and it works.

[qubesos-bot]

OpenQA test summary

Complete test suite and dependencies: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2026031319-4.3-debian&flavor=pull-requests

Test run included the following:

• splitgpg2: allow xauthority OPTION for Flatpak clients qubes-app-linux-split-gpg2#33 (QubesOS/qubes-app-linux-split-gpg2@db1c458)
• Introduce audio-volume feature qubes-core-admin-client#405 (QubesOS/qubes-core-admin-client@791d573)
• Integration tests for audio-initial-volume feature qubes-core-admin#768 (QubesOS/qubes-core-admin@6a38ab0)
• Add label to system_info qubes-core-admin#786 (QubesOS/qubes-core-admin@76e3517)
• Speed disposable performance tests without a GUI qubes-core-admin#787 (QubesOS/qubes-core-admin@3b7a41a)
• qrexec-policy-graph: add qube colors qubes-core-qrexec#222 (QubesOS/qubes-core-qrexec@f4e05be)
• qvm-appmenus: remove unstable-format gate for --get-available qubes-desktop-linux-common#72 (QubesOS/qubes-desktop-linux-common@e4cb94a)
• appmenus: update menus when template_for_dispvms changes qubes-desktop-linux-common#74 (QubesOS/qubes-desktop-linux-common@9789d4f)
• global config: fix unclickable dom0 file access link qubes-desktop-linux-manager#303 (QubesOS/qubes-desktop-linux-manager@dbb4d8b)
• Don't hang is-system-running when GUI is disabled qubes-gui-agent-linux#255 (QubesOS/qubes-gui-agent-linux@9129d1c)
• Allow user to set qube audio volume #174 (c4faa21)
• Fix odict deprecation warnings qubes-mgmt-salt-base-topd#16 (QubesOS/qubes-mgmt-salt-base-topd@e07e6fd)

New failures, excluding unstable

Compared to: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2026020304-devel&flavor=update

Failed tests

No failures!

Fixed failures

Compared to: https://openqa.qubes-os.org/tests/166096#dependencies
Nothing fixed

Unstable tests

Details

Performance Tests

Performance degradation:

No issues

Remaining performance tests:

13 tests

• debian-13-xfce_dom0-dispvm-api (mean:6.539): 78.47 🟢 ( previous job: 79.83, improvement: 98.29%)
• debian-13-xfce_dom0-dispvm-gui-api (mean:7.827): 93.92 🔻 ( previous job: 92.49, degradation: 101.55%)
• debian-13-xfce_dom0-dispvm-preload-2-api (mean:3.149): 37.79 🟢 ( previous job: 44.94, improvement: 84.08%)
• debian-13-xfce_dom0-dispvm-preload-2-delay-0-api (mean:2.917): 35.00 🟢 ( previous job: 41.46, improvement: 84.42%)
• debian-13-xfce_dom0-dispvm-preload-2-delay-minus-1d2-api (mean:3.307): 39.69 🟢 ( previous job: 47.01, improvement: 84.43%)
• debian-13-xfce_dom0-dispvm-preload-4-api (mean:2.284): 27.41 🟢 ( previous job: 37.67, improvement: 72.75%)
• debian-13-xfce_dom0-dispvm-preload-4-delay-0-api (mean:2.809): 33.71 🟢 ( previous job: 36.76, improvement: 91.71%)
• debian-13-xfce_dom0-dispvm-preload-4-delay-minus-1d2-api (mean:2.441): 29.29 🟢 ( previous job: 37.87, improvement: 77.36%)
• debian-13-xfce_dom0-dispvm-preload-2-gui-api (mean:4.989): 59.87 🔻 ( previous job: 55.58, degradation: 107.71%)
• debian-13-xfce_dom0-dispvm-preload-4-gui-api (mean:4.135): 49.62 🔻 ( previous job: 47.73, degradation: 103.97%)
• debian-13-xfce_dom0-dispvm-preload-6-gui-api (mean:4.198): 50.38 🔻 ( previous job: 47.11, degradation: 106.93%)
• debian-13-xfce_dom0-vm-api (mean:0.038): 0.45 🔻 ( previous job: 0.41, degradation: 109.93%)
• debian-13-xfce_dom0-vm-gui-api (mean:0.039): 0.47 🟢 ( previous job: 0.48, improvement: 96.67%)