Audio qube

[qqubes]

Yes, I did attach sys-audio to the bluetooth device in the GUI.

Still, when I run blueman in sys-audio, it sees my bluetooth devices, but it fails to connect with them.

[Mirai]

Following stuff installed (32 and 64bit versions) :

pipewire
pipewire-alsa
pipewire-gstreamer
pipewire-libs
pipewire-pulseaudio
pipewire-qubes
pipewire-utils
pulseaudio-libs
pulseaudio-libs-glib2
vlc-plugin-pipewire
wine-pulsaudio
xfce4-pulseaduio-plugin

[neowutran]

In that case, the easiest way is to merge the sys-audio and sys-usb qubes (or else it will probably require extensive debugging), at least for the controller that manage your bluetooth system. If you use a non minimal template for the sys-audio, add the needed pci device in the list of pci devices passthrough.

[apparatus]

Did you start the qube after sys-audio is started?
What’s the output of this command in the qube after it starts and sound is not working?

systemctl --user status wireplumber pipewire.service pipewire.socket pipewire-pulse.service pipewire-pulse.socket | cat

[nokke]

If I restart sys-audio (which happens frequently), client qubes don’t connect to the new sys-audio (it’s disposable), so I also have to restart them.

Is this normal, and is there a way to get a connection back without restarting a client qube?

[apparatus]

@nokke

If I restart sys-audio (which happens frequently), client qubes don’t connect to the new sys-audio (it’s disposable), so I also have to restart them.

Is this normal

Yes, or at least it was an like this before:

@neowutran

No sound in qubes started before audiovm

This issue is that the vchan modules of the pulseaudio/pipewire daemon running in the already started qubes are
not using the correct audiovm xid (ID of the xen vm).

If you are using pulseaudio: In standard setup, restarting the pulseaudio daemon is enough. Kill the
pulseaudio process and run “start-pulseaudio-with-vchan”.

If you are using pipewire (pipewire will be the default soon if not already the case):
systemctl --user restart pipewire

In special configuration, you may need to manually set the “domid” parameter of
the vchan modules.

@nokke

and is there a way to get a connection back without restarting a client qube?

It seems that dynamic audiovm switching was implemented:

Dynamic audiovm switching

But I don’t know if it’s working right now or not.

[Mirai]

I just noticed that it’s the same issue I had before switching to sys-audio.

Audio works fine for most VMs but after using certain VMs for a while it stops working.
(Even after complete system reboot)

I seems to me that there is no audio device
Even restarting pipewire doesn’t help anymore

EDIT
After restarting all the services and socket you mentioned I am able to see a dummy output device in pavucontrol in the VM but the Qube does not show up in pavucontrol of sys-audio

EDIT2
well now the dummy device stays after restarting the Qube and mpv doesn’t complain anymore that there is no jack. (still only the dummy device is visible in pacucontrol)

[Mirai]

Output of the freshly started Qube with no working audio (audiovm is set correctly)

● pipewire-pulse.socket - PipeWire PulseAudio
     Loaded: loaded (/usr/lib/systemd/user/pipewire-pulse.socket; enabled; preset: enabled)
     Active: active (listening) since Wed 2024-07-31 15:48:39 CEST; 8s ago
   Triggers: ● pipewire-pulse.service
     Listen: /run/user/1000/pulse/native (Stream)
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/pipewire-pulse.socket

Jul 31 15:48:39 mpv-qube systemd[816]: Listening on pipewire-pulse.socket - PipeWire PulseAudio.

○ pipewire-pulse.service - PipeWire PulseAudio
     Loaded: loaded (/usr/lib/systemd/user/pipewire-pulse.service; disabled; preset: disabled)
    Drop-In: /usr/lib/systemd/user/service.d
             └─10-timeout-abort.conf
     Active: inactive (dead)
TriggeredBy: ● pipewire-pulse.socket

● pipewire.socket - PipeWire Multimedia System Sockets
     Loaded: loaded (/usr/lib/systemd/user/pipewire.socket; enabled; preset: enabled)
     Active: active (running) since Wed 2024-07-31 15:48:39 CEST; 8s ago
   Triggers: ● pipewire.service
     Listen: /run/user/1000/pipewire-0 (Stream)
             /run/user/1000/pipewire-0-manager (Stream)
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/pipewire.socket

Jul 31 15:48:39 mpv-qube systemd[816]: Listening on pipewire.socket - PipeWire Multimedia System Sockets.

● pipewire.service - PipeWire Multimedia Service
     Loaded: loaded (/usr/lib/systemd/user/pipewire.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/user/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Wed 2024-07-31 15:48:39 CEST; 8s ago
TriggeredBy: ● pipewire.socket
   Main PID: 835 (pipewire)
      Tasks: 2 (limit: 856)
     Memory: 4.5M (peak: 4.7M swap: 728.0K swap peak: 768.0K)
        CPU: 20ms
     CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/pipewire.service
             └─835 /usr/bin/pipewire

Jul 31 15:48:39 mpv-qube systemd[816]: Started pipewire.service - PipeWire Multimedia Service.

● wireplumber.service - Multimedia Service Session Manager
     Loaded: loaded (/usr/lib/systemd/user/wireplumber.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/user/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Wed 2024-07-31 15:48:39 CEST; 8s ago
   Main PID: 836 (wireplumber)
      Tasks: 6 (limit: 856)
     Memory: 6.2M (peak: 6.5M swap: 1.3M swap peak: 1.4M)
        CPU: 44ms
     CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/wireplumber.service
             └─836 /usr/bin/wireplumber

Jul 31 15:48:39 mpv-qube systemd[816]: Started wireplumber.service - Multimedia Service Session Manager.
Jul 31 15:48:39 mpv-qube wireplumber[836]: wp-device: SPA handle 'api.libcamera.enum.manager' could not be loaded; is it installed?
Jul 31 15:48:39 mpv-qube wireplumber[836]: s-monitors-libcamera: PipeWire's libcamera SPA plugin is missing or broken. Some camera types may not be supported.
Jul 31 15:48:40 mpv-qube wireplumber[836]: default: Failed to get percentage from UPower: org.freedesktop.DBus.Error.NameHasNoOwner
Jul 31 15:48:40 mpv-qube wireplumber[836]: spa.bluez5: BlueZ system service is not available

[apparatus]

You have an issue with your audio device in sys-audio. Maybe some issue with driver/firmware.
Check the journalctl in your sys-audio to see if there are any errors related to it.
What’s your audio device?

[Mirai]

Audio works fine inside sys-audio, and for almost all other qubes as well.

It’s more like this xen bug:

@neowutran

Most user will never encounter such a case, but for people that have a LOT of qubes running, it is important to properly configure the audiovm property, it need to be empty for qubes that will never use audio

There is a maximum of ~19 qubes that can be running simultaneously without using audio (but with a audiovm configured). After that number, when a new qube is created, sys-audio will stop working. (xenstore quota issue, audiovm - Argument list too long - no sound for new qubes · Issue #8966 · QubesOS/qubes-issues · GitHub )

I have disabled the audiovm by default.

It’s just that, sometimes some qubes don’t wan’t to play audio anymore…
In the affected Qube the only audio device visible is the dummy one and inside sys-audio the affected Qube doesn’t even show up in pavucontrol. (While other Qubes play audio just fine). I had the same issue before sys-audio.

[Mirai]

I really don’t get it. Renamed (Cloned) the affected VM 3 times and now audio works again…
I have changed NOTHING not even a system reboot.

[neowutran]

With the VM that now have a working audio, restart it. Do you still have working audio in this VM ?

[Mirai]

Well not anymore. I restarted it a couple times before and it kept working. But now a few hours later, it doesn’t work anymore. (Done nothing more than playing Noise.wav with mpv)

qubesdb-read -w /qubes-audio-domain-xid

Is configured correctly (The same as other working Qubes)

EDIT:

restarting pipewire in sys-audio and the affected Qube did not help. But now after restarting sys-audio, audio started working again in the affected Qube. Why??? (a couple days ago this didn’t help)

[Mirai]

Started the ex problematic Qube again and surprise no audio.
But after restarting the audiovm, audio worked again. No clue at all what’s wrong here
This is behaving so weird that the root cause might be a hardware issue (No I don’t have Intel)

EDIT

Lost audio again (wanted to watch something). I am slowly loosing my mind

[neowutran]

I have no idea what is going on with your system :')
If I had the same issue I would try to:

• in priority, check if you have any resources issue, OOM, unexpected huge cpu consumption, in general or in your sys-audio or other vm …
• in sys-audio, run qvm-start-daemon manually with verbose mode
• check journalctl logs of sys-audio and the problematic vm

[alimirjamali]

@neowutran

Need to check what does the API do when it receive this event, probably the file “qubes/api/admin.py”

Any progress on this?

[QmanQtwo]

I’d like to share some things that have restored my sanity while solving the sound crackling / pw-top xruns / pipewire debug messages of “Client too slow!” errors…

My specific issue was that audio was fine-in-the-beginning-but-quickly-ramps-up-crackling-until-pure-robot-voices…
I found pw-top ERRs were skyrocketing, and found this to explain it:

Drops and errors on system load

api.alsa.headroom was the next target, and indeed it’s handled by wireplumber…

There’s a section, in /usr/share/wireplumber/main.lua.d/50-alsa-config.lua that defines what’ll happen if wireplumber detects it’s running in a VM:

  -- These properties override node defaults when running in a virtual machine.
  -- The rules below still override those.
  ["vm.node.defaults"] = {
    ["api.alsa.period-size"] = 256,
    ["api.alsa.headroom"] = 8192,
  },

Guess what wireplumber detects, even when sys-audio is a HVM with PCI passthroughs?
Yup, a vm. You can verify this settings’ value with:
wpctl status (to get the number of your default/primary Sink)
wpctl inspect ## (sink number)

What does api.alsa.headroom do?
https://pipewire.pages.freedesktop.org/wireplumber/daemon/configuration/alsa.html

This adds extra delay between the hardware pointers and software pointers. In most cases this can be set to 0. For very bad devices or emulated devices (like in a VM) it might be necessary to increase the headroom value.

So how do we set it?
Well, the wireplumber version in the debian-12-minimum template is $(wireplumber -v) [0.4.13] NOT the v5.5 that the current documentation is at, and there was a lua → SPA-JSON change to the formatting.
So we need to find the default configuration files that this version uses, and they’re located at:
/usr/share/wireplumber/main.lua.d/

They load in order of 01-whatever.lua to 90-enable-all.lua,
starting from /usr/share/wireplumber [shipped defaults]
then /etc/wireplumber [system wide settings]
then ~/.config/wireplumber [user settings]
With the latest read overriding the previous.

This can be set in the app-vm or template, by creating a .lua file in the above location of your choice (I’ve found that, aside from packages, all the audio modification I’ve needed to make can be done in the app-vm itself - making it quicker to Salt + deploy + test)

In my case, the crackling issues disappeared when I set api.alsa.headroom to 0, with the following file

/home/user/.config/wireplumber/main.lua.d/89-headroom.lua:
  file.managed:
    - mode: '0644'
    - user: user
    - group: user
    - makedirs: True
    - contents: |
        alsa_monitor.properties = {
          ["vm.node.defaults"] = {
           ["api.alsa.headroom"] = 0,
          },
        }

Which seems counterintuitive at first, but the issue was data not getting to the right place at the right time - I thought the hardware needed a bigger buffer (quantum in pipewire terms), but it was being choked instead.

Now Easyeffects is running with plenty of audio modifications smooth as can be, and while I didn’t notice this at first, there’s no audio delay in daily videos as well! I do notice xruns or crackling but it’s sanely coming from large spikes in disk or CPU usage, whew.

You can set headroom, default volume, how profiles are loaded from pci and usb devices, and suspend in the same file, combining 40-device-defaults.lua and 50-alsa-config.lua modifications.
In Wireplumber, Devices are the hardware, and Nodes(Sinks) are the interface to that hardware.

/home/user/.config/wireplumber/main.lua.d/89-combined.lua:
  file.managed:
    - mode: '0644'
    - user: user
    - group: user
    - makedirs: True
    - contents: |
        device_defaults.properties = {
          ["default-volume"] = 1.0,
          ["default-input-volume"] = 1.0,
        }
        alsa_monitor.enabled = true
        alsa_monitor.properties = {
          -- These properties override node defaults when running in a virtual machine.
          -- The rules below still override those.
          ["vm.node.defaults"] = {
           ["api.alsa.headroom"] = 0,
          },
        }
        alsa_monitor.rules = {
          {
            matches = {
              {
                { "device.name", "matches", "alsa_card.pci*" },
              },
            },
            apply_properties = {
              ["api.alsa.use-acp"] = true,
              ["api.alsa.use-ucm"] = true,
              ["api.acp.auto-profile"] = false,
              ["api.acp.auto-port"] = false,
            },
          },
          {
            matches = {
              {
                { "device.name", "matches", "alsa_card.usb*" },
              },
            },
            apply_properties = {
              ["api.alsa.use-acp"] = true,
              ["api.alsa.use-ucm"] = true,
              ["api.acp.auto-profile"] = false,
              ["api.acp.auto-port"] = false,
            },
          },
          {
            matches = {
              {
                -- Matches all sources.
                { "node.name", "matches", "alsa_input.*" },
              },
              {
                -- Matches all sinks.
                { "node.name", "matches", "alsa_output.*" },
              },
            },
            apply_properties = {
              ["api.alsa.headroom"]      = 0,
              ["session.suspend-timeout-seconds"] = 0,  -- 0 disables suspend
            },
          },
        }

I believe the bulk of settings to change can be found in /usr/share/wireplumber/main.lua.d/50-alsa-config.lua and inserted under the last apply_properties section.
Hope this helps someone else

[neowutran]

Nice finding !

If others people confirm that it solved this issue they had (I don’t personally have the issue mentioned, but probably because I use a fedora template instead of a debian one), it should be integrated in the guide.

For fedora template, wireplumber is in version 5.5 and different default values, value reported is 512 or 256

small extract from my system:

    api.alsa.headroom = "512"
    api.alsa.period-num = "64"
    api.alsa.period-size = "512"

[PostedPortal]

will there be any efforts to make sys-audio a default qube that comes with sys-usb, sys-net etc…

[neowutran]

Since it is the QubesOS teams that make most of the work to have a working sys-audio, yes probably, but not now.
If you want to speed up the process there are multiple things that can be done. At least the following things:

• 1. Solve all the known issues:
  • Keyboard layout switching issue
  • Autoreconnect to audio vm when audio vm is restarted
  • … ?
• 2. Convert the current community guide to an official guide (check if you can improve it, review it, pull request … )
• 3. Review + improve + pull request of the Salts files to automate installation of sys-audio
• 4. Eventually, a new option in the QubesOS installer to apply the sys-audio salts