In case anyone else is looking for a more official source for the RPC policy for an audio qube, I found this one in the qubes-mgmt-salt-dom0-virtual-machines repository. You can switch to the branch for your Qubes OS version if it makes a difference.
But did you test it? ![]()
Yes, on my Qubes 4.2 system, I followed most of the guide but with the RPC policy from the repository in place of the one from the guide. In a simple test, I was able to both play and record audio in a VM other than the AudioVM, despite some RPC denial notifications. I experienced some glitches that I havenât investigated, but I donât think they were related to RPC policy. Because my motivation for using an AudioVM was to use Bluetooth headphones, not concern about the attack surface of audio in dom0, I decided to revert to audio in dom0 so I donât have to live with the glitches unless/until I need the AudioVM again.
The two policy files are very similar, as you can see if you diff them (it helps to sort the lines first). AFAICT the only things allowed by the policy in the guide and not in the repository are admin.vm.feature.CheckWithTemplate +audio-low-latency and +supported-service.pipewire; those might be relevant to features I didnât test. The policy in the guide also suppresses the denial notifications for admin.vm.property.GetAll. The policy in the repository provides an alternative for security-conscious users who feel itâs sufficiently clear that most of the guide is harmless but arenât sure about the policy, which was my case.
So, my HVM owns dGPU and its audio device. HVM is sent to TV via HDMI/DP. HVMâs audiovm is set to sys-audio, but naturally no sound there, because sys-audio doesnât own sound device and the only way to get the audio is on TVâs speakers.
Can I get this HVMâs audio via sys-audio at all? I am not sure I can split dGPU to HVM and its audio device to sys-audio and HVM to start successfully.
For the sake of clarity, Iâm replying to myself:
Actually it is possible to split audio device from its dGPU and to assign it to sys-audio and everything works smoothly!
Jesus, and I tortured myself for so long with a shitty TV sound, so thanks @solene for an inspiration!
Now, new idea: does it make sense to create separate sys-audio for each audio device for the goal of compartmentalization?
Thank you so much for this post! Itâs really help me!
Sys-audio qube doesnât work for Windows HVM. Canât set as audio-vm. I am using 4.2
Tested it, it seems to be broken. module-vchan-sink seems to be ignoring the domid parameter. Havenât tried to debug it yet
This breaks when upgrading the other qubes (not audio qube) from debian 12 to 13. Does anyone have any ideas?
Turned out itâs because I did a manual upgrade instead of swapping the template where some packages broke
This guide up to date?
Stuck at Audio qube , V56, 4.3.0rc2, from this point donât have any sound from device.
also service audiovm donât available for choose in sys-audio services.
You need to add custom services (by typing it names):
audiovm
network-manager
where network-manager must be unchecked (so itâs not loading, but without it, it wonât be recognized as service qube)
Look like big step forward, now I can see additional sound bar control related to sys-audio.
But in settings it donât show any audio devices, only microphone.
Within sys-audio:
aplay /usr/share/sounds/alsa/Noise.wav
Result in error:
aplay main:850: audio open error: Host is down
Yes and strict reset was requested to start sys-audio after that.
Does alsactl info shows any cards?
$ alsactl info
#
# Sound card
#
- card: 0
id: PCH
name: HDA Intel PCH
longname: HDA Intel PCH at 0xf2100000 irq 59
driver_name: HDA-Intel
mixer_name: Realtek ALC257
components: HDA:10ec0257,17aa22e8,00100001 HDA:8086281c,80860101,00100000
controls_count: 16
pcm:
- stream: PLAYBACK
devices:
- device: 0
id: ALC257 Analog
name: ALC257 Analog
subdevices:
- subdevice: 0
name: subdevice #0
- stream: CAPTURE
devices:
- device: 0
id: ALC257 Analog
name: ALC257 Analog
subdevices:
- subdevice: 0
name: subdevice #0
alsactl: rawmidi_device_list:109: snd_ctl_rawmidi_next_device: Inappropriate ioctl for device
Yes, it is and very similar to your info report.
Just with another realtek model
systemctl --user status pipewire{,-pulse} wireplumber
is everything active and running?
active, but with 3 errors:
*data, time* sys-audio systemd[737]: Started pipewire.service - PipeWire Multimedia service.
*data, time* sys-audio pipewire[736]: mod.qubes-audio no /qubes-audio-domain-xid entry in QubesDB
*date, time* sys-audio pipewire[736] mod.qubes-audio: unknown peer domain, cannot create stream
*date, time* sys-audio pipewire[736]: mod.qubes-audio: unknown peer domain, cannot create stream
you could run it in template or in sys-audio
sudo dnf list --installed pipewire-qubes

