Using an external sound card in Qubes OS 4.3

2026-10-30T00:00:00+00:00

Disclaimer

Claude was used to debug problems and to help write this article. Despite this, the content has been proof-read and tested by yours truly.

If for some reason you believe shared AI authorship takes value away from this post, please feel under no obligation to read or follow its contents.

Overview

This guide is the result of my efforts to try and make my USB sound card work under Qubes. Unfortunately, by default, Qubes only supports one audio card which stays attached to the dom0.

These instructions take you from a default Qubes setup to one with a special audio qube (sys-audio), that manages both the integrated audio chip and the USB one(s).

The end state: sys-audio owns the internal PCI sound card permanently and receives the USB sound card automatically whenever it is plugged in. PipeWire inside sys-audio switches playback to the USB card when it appears and falls back to the internal card when it is unplugged. App qubes never notice.

Only sys-audio touches sound hardware; dom0 hands over the internal card at boot and sys-usb passes the USB card through on each plug.

Written for Qubes OS 4.3 (dom0 on Fedora 41) with the debian-13-minimal template. Commands marked dom0 run in a dom0 terminal; commands marked template or sys-audio run in that qube.

What you trade:

dom0 no longer plays sound itself. Volume control moves to a tray icon from sys-audio and rebound volume keys (Step 8).
sys-usb and dom0 stay out of the audio path. dom0 never touches the USB card.
The USB card's audio travels through the Qubes USB proxy from sys-usb to sys-audio. Some cards crackle this way at high sample rates. Test yours early (Step 6).
Qubes already running when sys-audio starts get no sound until restarted, so sys-audio autostarts at boot.

Before you start: back up, and keep a dom0 terminal open. Everything here is reversible; the rollback is at the end.

Step 1: Build the audio template

Clone a fresh minimal template so your other qubes are untouched.

dom0:

qvm-template install debian-13-minimal      # skip if already installed
qvm-clone debian-13-minimal deb13-audio
qvm-run -u root deb13-audio xterm &

Minimal templates have no passwordless sudo, which is why the shell above runs as root.

template (root xterm in deb13-audio):

apt update && apt full-upgrade -y
apt install -y \
  pipewire-qubes qubes-audio-daemon qubes-core-admin-client qubes-usb-proxy \
  pipewire pipewire-pulse pipewire-alsa wireplumber pulseaudio-utils \
  alsa-utils alsa-ucm-conf pavucontrol pasystray
# pipewire-alsa routes ALSA tools (aplay, speaker-test) through PipeWire,
# so they follow the same default output as everything else

What each group is for:

pipewire-qubes, qubes-audio-daemon: receive audio streams from other qubes.
qubes-core-admin-client: lets sys-audio see which qubes exist and start their audio connections.
qubes-usb-proxy: required to receive the USB card from sys-usb.
pipewire-pulse, wireplumber, pulseaudio-utils: the sound server, its session manager, and pactl.
pavucontrol, pasystray: mixer window and tray icon.

If apt reports a conflict between pulseaudio and pipewire-*, remove pulseaudio but keep qubes-audio-daemon. If apt wants to remove qubes-audio-daemon too, stop and check the Audio qube forum guide for the current workaround.

Stop speaker pops caused by the internal card's power saving:

echo 'options snd_hda_intel power_save=0' > /etc/modprobe.d/50-snd.conf

Recent Intel laptops often need Sound Open Firmware. If the internal card later shows no outputs, enable the non-free-firmware component in /etc/apt/sources.list.d/ and apt install firmware-sof-signed.

Shut the template down when done.

dom0:

qvm-shutdown --wait deb13-audio

Step 2: Create the sys-audio qube

Use a regular app qube, not a disposable, so mixer settings and the tray autostart persist.

dom0:

qvm-create --class AppVM --template deb13-audio --label red sys-audio
qvm-prefs sys-audio netvm ''           # no network needed
qvm-prefs sys-audio virt_mode hvm      # required for PCI passthrough
qvm-prefs sys-audio memory 1000
qvm-prefs sys-audio maxmem 0           # turns off memory balancing
qvm-prefs sys-audio autostart True
qvm-prefs sys-audio audiovm ''         # it plays its own sound locally
qvm-service sys-audio audiovm on       # marks it as an audio qube

The same settings exist in Qube Settings: Basic (template, networking, autostart), Advanced (HVM mode, memory, untick memory balancing), Services (add audiovm).

Don't start it yet.

Step 3: Give the internal sound card to sys-audio

This takes three parts: pick the right device, assign it, and stop dom0 from grabbing it at boot.

3a. Find the audio controller

dom0:

qvm-pci list | grep -iE 'audio|multimedia'
lspci -nn | grep -iE 'audio|multimedia'      # same devices, with bus addresses and classes

You want the line that is an Audio device (class [0403]) driving the speakers and headphone jack. Never assign a PCI bridge (class [0604]); see the troubleshooting section if sys-audio reports a non-endpoint device.

Intel: usually one ID such as dom0:00_1f.3. Assign only that function; leave the other 00:1f.x functions (ISA bridge, SMBus, SPI) in dom0.
AMD: audio sits behind a bridge, and Qubes 4.3 shows the path in the ID, e.g. dom0:00_08.1-00_00.6. There are usually three functions: .6 is the HD Audio Controller (assign it), .5 is the Audio Coprocessor that often runs the built-in digital mics (assign only if you want the internal mic), .1 is the GPU's HDMI audio (leave in dom0).

3b. Assign it

dom0:

qvm-pci assign --required -o no-strict-reset=True sys-audio dom0:00_1f.3
# AMD example:
# qvm-pci assign --required -o no-strict-reset=True sys-audio dom0:00_08.1-00_00.6
# qvm-pci assign --required -o no-strict-reset=True sys-audio dom0:00_08.1-00_00.5   # optional, internal mic

no-strict-reset is needed on most laptops. Onboard audio usually can't be reset on its own, and on AMD it shares a bus with the integrated GPU, which dom0 always uses, so a bus reset is never possible. It means the card isn't wiped between qubes, which matters little here because only sys-audio ever uses it. On a desktop where it isn't needed, you can try without it first.

3c. Hide the card from dom0 at boot

Otherwise dom0's sound driver claims the card first and sys-audio fails to start because the device is in use. Take the bus address from the lspci output (e.g. 00:1f.3 on Intel, c1:00.6 on AMD, not the Qubes path ID).

dom0: edit /etc/default/grub as root. In the GRUB_CMDLINE_LINUX line there is usually already an rd.qubes.hide_pci= list holding your USB controllers. Append the audio address(es) to that same list with commas; don't add a second rd.qubes.hide_pci= entry:

# before: rd.qubes.hide_pci=<existing USB controller entries>
# after:  rd.qubes.hide_pci=<existing USB controller entries>,c1:00.6,c1:00.5

Keep the existing entries exactly as they are: they are your USB controllers, hidden so sys-usb gets them. You only append. If there is no rd.qubes.hide_pci yet, add one with just the audio addresses.

Then regenerate the boot configuration:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

The reboot in Step 5 applies it. If you leave out the coprocessor later, remove its address from this list too.

Step 4: Allow sys-audio to see its client qubes

sys-audio must query dom0 for which qubes use it, their state and their audio features. Qubes tags every qube whose audio qube is sys-audio with audiovm-sys-audio automatically; the policy grants read access to those qubes only.

dom0:

sudo tee /etc/qubes/policy.d/50-sys-audio.policy > /dev/null <<'EOF'
admin.Events          *  sys-audio  sys-audio               allow target=dom0
admin.Events          *  sys-audio  @adminvm                allow target=dom0
admin.Events          *  sys-audio  @tag:audiovm-sys-audio  allow target=dom0
admin.vm.CurrentState *  sys-audio  @adminvm                allow target=dom0
admin.vm.CurrentState *  sys-audio  @tag:audiovm-sys-audio  allow target=dom0
admin.vm.List         *  sys-audio  @adminvm                allow target=dom0
admin.vm.List         *  sys-audio  @tag:audiovm-sys-audio  allow target=dom0

admin.vm.property.Get +audiovm     sys-audio  @tag:audiovm-sys-audio  allow target=dom0
admin.vm.property.Get +xid         sys-audio  @tag:audiovm-sys-audio  allow target=dom0
admin.vm.property.Get +stubdom_xid sys-audio  @tag:audiovm-sys-audio  allow target=dom0
admin.vm.property.Get +virt_mode   sys-audio  @tag:audiovm-sys-audio  allow target=dom0
admin.vm.property.Get +klass       sys-audio  @tag:audiovm-sys-audio  allow target=dom0
admin.vm.property.Get +is_preload  sys-audio  @tag:audiovm-sys-audio  allow target=dom0

admin.vm.feature.CheckWithTemplate +audio                      sys-audio  @tag:audiovm-sys-audio  allow target=dom0
admin.vm.feature.CheckWithTemplate +audio-model                sys-audio  @tag:audiovm-sys-audio  allow target=dom0
admin.vm.feature.CheckWithTemplate +supported-service.pipewire sys-audio  @tag:audiovm-sys-audio  allow target=dom0
admin.vm.feature.CheckWithTemplate +audio-low-latency          sys-audio  @tag:audiovm-sys-audio  allow target=dom0

# silence harmless requests it doesn't need
admin.vm.feature.CheckWithTemplate +gui  sys-audio  @tag:audiovm-sys-audio  deny notify=no
admin.vm.property.GetAll           *     sys-audio  @tag:audiovm-sys-audio  deny notify=no
EOF

This follows the current community Audio qube guide for 4.3, including later fixes from its thread. If you see policy-denied notifications mentioning sys-audio after Step 5, the notification names the missing call; add an allow line for it in the same style.

Step 5: Switch the system to sys-audio and reboot

dom0:

qubes-prefs default_audiovm sys-audio

Check for qubes that override the default, for example ones you set to dom0 earlier:

qvm-ls --raw-data --fields NAME,AUDIOVM
qvm-prefs --default <qube> audiovm     # reset an override to the default

Reboot the machine. A reboot hands the internal card cleanly from dom0 to sys-audio and autostarts sys-audio early in boot, so qubes you open afterwards connect to it.

After login, play a sound in any app qube. It should come out of the laptop speakers or headphone jack, now via sys-audio. Don't continue until this works; the troubleshooting section covers the usual causes.

Step 6: Auto-attach the USB sound card

Qubes 4.3 assignments do this natively. A plain assignment (without --required) attaches the card whenever it appears and never blocks sys-audio from booting if sys-usb or the card is missing.

Plug the card in, then in dom0:

qvm-usb                                          # note its ID, e.g. sys-usb:2-1
qvm-usb assign --device sys-audio sys-usb:2-1

--device matches the card's identity (vendor, product, serial) on any port. Use --port instead to attach whatever is plugged into that one port. Add --ask if you want a confirmation prompt before each attach.

Unplug and re-plug the card, then confirm:

qvm-usb list -s                                  # -s adds assignments to the listing
qvm-run -p sys-audio 'pactl list short sinks'    # an alsa_output.usb-... sink appears

How to read qvm-usb: the first column always starts with sys-usb: because it names where the device comes from, not where it is attached. That never changes. Look at the column on the right instead: it should show sys-audio once the card is attached, and with -s an asterisk (*sys-audio) marks the assignment.

Now test quality before relying on it: play music for a few minutes through the USB card, at the sample rate you normally use. If it crackles or drops out over the USB proxy, try a lower sample rate in Step 7 before giving up on the setup.

To undo: qvm-usb unassign --device sys-audio sys-usb:2-1.

Make sys-audio start after sys-usb

With a USB assignment in place, Qubes tries to auto-attach the card the moment sys-audio starts, which needs sys-usb to be fully up. At boot both autostart together, so sys-audio can fail with Start failed: (2, 'No such file or directory') while a manual qvm-start later works. Order the two autostart units:

dom0:

systemctl list-units 'qubes-vm@*'      # both qubes-vm@sys-usb and qubes-vm@sys-audio should be listed
sudo mkdir -p /etc/systemd/system/qubes-vm@sys-audio.service.d
printf '[Unit]\nAfter=qubes-vm@sys-usb.service\n' | \
  sudo tee /etc/systemd/system/qubes-vm@sys-audio.service.d/after-sys-usb.conf
sudo systemctl daemon-reload

qubes-vm@sys-usb only counts as finished once sys-usb is fully started, qrexec included.

Step 7: Make PipeWire prefer the USB card

WirePlumber picks the default output by priority and by what you last chose. Raising the USB card's priority makes it win whenever it is present, and the internal card takes over when it disappears. Settings in sys-audio's home folder persist across reboots.

Open a terminal in sys-audio from dom0: qvm-run sys-audio xterm &

sys-audio:

mkdir -p ~/.config/wireplumber/wireplumber.conf.d
cat > ~/.config/wireplumber/wireplumber.conf.d/51-prefer-usb.conf <<'EOF'
monitor.alsa.rules = [
  {
    matches = [ { node.name = "~alsa_output.usb-.*" } ]
    actions = { update-props = { priority.session = 2000, priority.driver = 2000 } }
  }
]
EOF
systemctl --user restart wireplumber pipewire pipewire-pulse

Then set the USB card as default once, so the remembered choice and the priority agree. Run wpctl status, find the USB card's number under Audio → Sinks, and run wpctl set-default <number>. WirePlumber remembers this across reboots and replugs. Ticking the card as fallback in pavucontrol (Output Devices tab) does the same.

Check with wpctl status: the asterisk under Sinks marks the current default. Unplug the card and it moves to the internal card within a second or two; plug it back and it returns.

Two things that look wrong but aren't:

pactl list short sinks shows both cards as SUSPENDED. PipeWire suspends any output that is idle; it switches to RUNNING as soon as something plays.
To test inside sys-audio, use pw-play /usr/share/sounds/alsa/Front_Center.wav or paplay rather than speaker-test. Without pipewire-alsa, speaker-test bypasses PipeWire and always plays on the first hardware card. App qubes always follow the WirePlumber default, so the decisive test is playing something in an app qube.

Optional, if the USB card crackled in Step 6: fix the sample rate at 48 kHz.

mkdir -p ~/.config/pipewire/pipewire.conf.d
cat > ~/.config/pipewire/pipewire.conf.d/10-rate.conf <<'EOF'
context.properties = {
  default.clock.rate          = 48000
  default.clock.allowed-rates = [ 44100 48000 ]
}
EOF
systemctl --user restart wireplumber pipewire pipewire-pulse

Step 8: Volume control from the panel and keyboard

The dom0 XFCE volume applet now controls an output with no hardware behind it. Replace it with a tray icon from sys-audio and point the volume keys at sys-audio.

Tray icon. Start pasystray with every boot of sys-audio.

sys-audio:

mkdir -p ~/.config/autostart
cat > ~/.config/autostart/pasystray.desktop <<'EOF'
[Desktop Entry]
Type=Application
Name=pasystray
Exec=pasystray
EOF

Its icon appears in the dom0 panel with sys-audio's red border. Left click shows volume and output choice; middle click mutes; the menu opens pavucontrol for per-app volume.

Remove the old applet. In dom0, right-click the XFCE PulseAudio plugin → Remove. Removing it also frees the volume keys it was grabbing.

Volume keys. Bind the media keys to pactl in sys-audio. @DEFAULT_SINK@ follows whichever card is active, so the keys control the USB card when plugged and the internal one otherwise.

dom0:

set_key() {
  xfconf-query -c xfce4-keyboard-shortcuts -p "/commands/custom/$1" -n -t string \
    -s "qvm-run -q --no-gui sys-audio '$2'"
}
set_key XF86AudioRaiseVolume 'pactl set-sink-volume @DEFAULT_SINK@ +5%'
set_key XF86AudioLowerVolume 'pactl set-sink-volume @DEFAULT_SINK@ -5%'
set_key XF86AudioMute        'pactl set-sink-mute @DEFAULT_SINK@ toggle'
set_key XF86AudioMicMute     'pactl set-source-mute @DEFAULT_SOURCE@ toggle'

The same bindings can be made by hand in Settings → Keyboard → Application Shortcuts.

Microphone. The internal microphone now belongs to sys-audio too. Attach it to a qube from the Qubes Devices widget as before; it is listed under sys-audio instead of dom0, though how the widget labels it may differ.

Testing, troubleshooting and rollback

Final checklist

After a cold boot, an app qube plays through the internal speakers with the USB card unplugged.
Plugging the card in moves playback to it within a few seconds, without restarting anything.
Unplugging moves playback back to the internal speakers.
Booting with the card already plugged in sends sound to the USB card.
Tray icon and volume keys control whichever card is active.
A few minutes of music through the USB card play without crackles.

Troubleshooting

Symptom	Likely cause	Fix
No sound in a qube that was already running	It started before sys-audio	Restart that qube
No sound in any qube	Policy missing a line, or audiovm service not set	Check policy-denied notifications; `qvm-service sys-audio` must list `audiovm`
sys-audio won't start, PCI error	Card can't reset	Re-assign with `no-strict-reset=True` (Step 3)
Only a "Dummy Output" in pavucontrol	Internal card has no driver or firmware	Run `aplay -l` in sys-audio; install `firmware-sof-signed` (Step 1)
USB card not attached after replug	Assignment missing or made by port	`qvm-usb list -s` shows assignments with `*`; redo Step 6 with `--device`
USB card attached but sound stays internal	Remembered default overrides priority	Pick USB in pavucontrol; check the rule in Step 7 matches `wpctl status` names
Crackling on the USB card	USB proxy at high sample rates	Fix 48 kHz (Step 7); try another USB port
Audio drops after sys-usb restarts	Card detached with it	Should re-attach on its own; if not, replug

Useful logs, in sys-audio: journalctl --user -u pipewire -u wireplumber -b and journalctl -b | grep -i qubes-audio.

"Non-endpoint PCI devices cannot be assigned to guests"

sys-audio fails to start with this error when a PCI bridge was assigned instead of the sound card itself. Xen can't pass a bridge to a qube. It is easy to do on AMD laptops, where the audio devices sit behind a bridge.

Qubes 4.3 shows that path in the device ID: dom0:00_08.1-00_00.6 means function 00.6 behind bridge 00:08.1. Assigning dom0:00_08.1 alone assigns the bridge.

Example from a Rembrandt-era AMD laptop (qvm-pci list -s | grep -i audio):

Device ID	What it is	Assign to sys-audio?
`dom0:00_08.1-00_00.6`	HD Audio Controller: speakers and headphone jack	Yes
`dom0:00_08.1-00_00.5`	Audio Coprocessor (ACP): usually the built-in digital mics	Only if you want the internal mic in sys-audio
`dom0:00_08.1-00_00.1`	Radeon HD Audio: HDMI/DisplayPort audio from the GPU	No, leave it with the GPU in dom0

dom0:

qvm-pci list -s                                            # find the line marked *sys-audio
qvm-pci unassign sys-audio dom0:00_08.1                    # remove the bridge
qvm-pci assign --required sys-audio dom0:00_08.1-00_00.6   # the audio controller
qvm-pci assign --required sys-audio dom0:00_08.1-00_00.5   # optional: internal mic
qvm-start sys-audio

To double-check a device before assigning it, run lspci -nn -s <bus:dev.fn> in dom0: class [0604] is a bridge, [0403] or [0401] is audio. If startup then fails with a reset error, re-assign with -o no-strict-reset=True (Step 3).

PCI reset errors when starting sys-audio

"Can't reset ... active in dom0" / device in use. dom0's sound driver claimed the card at boot. Hide it from dom0 with rd.qubes.hide_pci (Step 3c) and reboot. For a one-off test without rebooting, release it by hand in dom0:

systemctl --user stop pipewire pipewire-pulse wireplumber 2>/dev/null; pulseaudio --kill 2>/dev/null
echo 0000:c1:00.6 | sudo tee /sys/bus/pci/drivers/snd_hda_intel/unbind    # your bus address
qvm-start sys-audio

"Can't reset c1:00.5 as c1:00.6 is active on the same bus". The functions share a bus (on AMD, together with the integrated GPU) and only support a whole-bus reset, which Xen won't do while anything on the bus is in use. Re-assign every audio function with no-strict-reset:

qvm-pci unassign sys-audio dom0:00_08.1-00_00.5
qvm-pci assign --required -o no-strict-reset=True sys-audio dom0:00_08.1-00_00.5
qvm-pci unassign sys-audio dom0:00_08.1-00_00.6
qvm-pci assign --required -o no-strict-reset=True sys-audio dom0:00_08.1-00_00.6

If you don't need the built-in microphone, dropping the coprocessor (.5) from both the assignment and rd.qubes.hide_pci is simpler.

Sound plays on the built-in card instead of USB

Set the USB card as default with wpctl set-default and add the priority rule (Step 7). If only speaker-test or aplay play on the built-in card while app qubes use USB, pipewire-alsa is missing from the template (Step 1).

sys-audio doesn't autostart: "Start failed: (2, 'No such file or directory')"

The qubesd log (sudo journalctl -b -u qubesd) shows the qube getting as far as Activating qube and then failing, while qvm-start sys-audio after login works. The USB auto-attach ran before sys-usb's qrexec was ready. Add the systemd ordering rule from Step 6. To confirm the cause first, unplug the card and reboot: without it, sys-audio autostarts normally.

Rollback

dom0:

qubes-prefs default_audiovm dom0
qvm-usb unassign --device sys-audio sys-usb:2-1
qvm-pci unassign sys-audio dom0:00_1f.3
qvm-prefs sys-audio autostart False

Also remove the audio addresses from rd.qubes.hide_pci in /etc/default/grub and run sudo grub2-mkconfig -o /boot/grub2/grub.cfg, or dom0 still won't see the card.

Then reboot. dom0 gets its sound card back, and you can re-add the XFCE volume applet. Delete sys-audio, deb13-audio and the policy file once you're sure.

Sources

Audio qube community guide and its later policy fixes (#426, #479)
qvm-device manual (assign, --device, --required)
Debian-minimal template for sys-audio
Debian 13 templates announcement

Alessandro's blog

Using an external sound card in Qubes OS 4.3

Disclaimer

Overview

Step 1: Build the audio template

Step 2: Create the sys-audio qube

Step 3: Give the internal sound card to sys-audio

3a. Find the audio controller

3b. Assign it

3c. Hide the card from dom0 at boot

Step 4: Allow sys-audio to see its client qubes

Step 5: Switch the system to sys-audio and reboot

Step 6: Auto-attach the USB sound card

Make sys-audio start after sys-usb

Step 7: Make PipeWire prefer the USB card

Step 8: Volume control from the panel and keyboard

Testing, troubleshooting and rollback

Final checklist

Troubleshooting

"Non-endpoint PCI devices cannot be assigned to guests"

PCI reset errors when starting sys-audio

Sound plays on the built-in card instead of USB

sys-audio doesn't autostart: "Start failed: (2, 'No such file or directory')"

Rollback

Sources