Eh, nevermind. Everything works well except for my fedora-based dvms (where the ALSA logs come from). Maybe I just messed up the template or something.
Removing the conflicting package
pipewire-pulseaudio can be accomplished very easily in a single step by running the
dnf install command with the extra flag
following your comment i modified the list of packages to install. Using pipewire instead of pulseaudio for sys-audio
Another feedback: on my Fedora 38 template I couldn’t find pulseaudio daemon or the
start-pulseaudio-with-vchan command. Instead the pipewire daemon is running.
To restart pipewire when needed I ran this command:
systemctl --user restart pipewire
Thanks, added a note about pulseaudio/pipewire setup difference. Can probably be improved
Thanks! This looks great, and I look forward to trying it. Is an audio-vm qube officially suggested as a best practice? I ask because it is not the default and I don’t want to make my qubes use even more complicated if troubleshooting arises later. The use cases you mentioned, though, sound tempting
Thanks for starting this. Running 4.2-rc4 atm, I followed the guide and got no errors but the audio isn’t actually forwarding or arriving at sys-audio (not using the dispvm), and I’m at a loss how to debug this. Sound playback inside sys-audio works fine, but in the domU from which I’m hoping to send the audio I don’t see any streams if I open pavucontrol; nor do I see anything incoming in the playback section in sys-audio.
in dom0 what is the result of
qubes-prefs default_audiovm ? in dom0 what is the output of
qvm-features sys-audio ? in sys-audio what is the output of
ps -ef | grep qvm-start-daemon ? What have you done for the
Configuring policy part ?
Also make sure that qvm-prefs shows sys-audio (not dom0) as the audiovm.
(One trap that sometimes gets people is that sys-audio is marked as its own audiovm so you can’t shut it down…so obviously you want to unset that, if it happens to be that way.)
Okay, made decent progress. I had tried your “recommended way” of creating the policy in dom0 but forgot to apply the patches you mentioned. Didn’t have time for that atm so for now I switched to the non recommended way of setting the policy. Now at least the streams are showing up in sys-audio playback.
Main remaining problems now are that the pipewire service doesn’t always seem to automatically start in the source VMs and that the watch daemon in sys-audio isn’t always picking up on new VMs starting (especially when pipewire service isn’t running from the start, I guess).
This is a community guide, not an officially endorsed doc or anything like that.
QubesOS core team are creating and improving the software required to have a audiovm and guivm (and this guide is using their work ).
In the futur QubesOS will maybe/probably recommend to use a audiovm & guivm if feasible.
Currently this guide is a community best effort based on a WIP, it still work quite well but expect to have troubleshooting to do
I tried this today but ran into some trouble when testing the sound in sys-audio.
Executing the command I got the message:
audio open error: host is down
Journalctl gives me lots of error messages referring to pipewire:
Nov 15 10:10:33 sys-audio pipewire: mod.qubes-audio: org.qubes-os.audio-domain-xid not specified, and no /qubes-audio-domain-xid entry in QubesDB Nov 15 10:10:33 sys-audio pipewire: pw.conf: 0x648c3bd241d0: could not load mandatory module "libpipewire-module-qubes": No such file or directory Nov 15 10:10:33 sys-audio pipewire: default: failed to create context: No such file or directory Nov 15 10:10:33 sys-audio systemd: pipewire.service: Main process exited, code=exited, status=254/n/a Nov 15 10:10:33 sys-audio systemd: pipewire.service: Failed with result 'exit-code'.
I looked at the pipewire-pulse.service and it says it is running.
[user@sys-audio ~]$ systemctl --user status pipewire-pulse.service ● 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: active (running) since Wed 2023-11-15 10:11:21 CET; 6h ago TriggeredBy: ● pipewire-pulse.socket Main PID: 914 (pipewire-pulse)
Do I have to have other services enabled? I am not so sure what is wrong because this is not the first sys-audio guide I tried. I got further before but unfortunately the sound is not working with sys-audio so far.
Any help how to find out what’s wrong is welcome.
Also I would like to patch the source code but haven’t done this in ages. I do need the qubes builder and build the package myself including the patch, don’t I? Or is this merged already?
For now I have copied the rules from the non recommended way.
Hello, I would like to ask if anyone else is having issues with the microphone side of using this? I do have audio working in pipewire but I could not get pulseaudio to work. While using pipewire passing my microphone(dom0 audio input) into a vm does not reliably work and constantly cuts in an out every half second or so with 3-4 seconds of delay. Im lost on how I would debug and fix this issue, any help to fix this issue would be appreciated.
some weeks ago a patch have been added to solve this, in your audiovm can you try to execute
grep low_latency /usr/lib/python3.11/site-packages/qubesadmin/tools/qvm_start_daemon.py
(just to be sure you are up-to-date )
Hi, I executed that command in my audiovm and got back
low_latency = not vm.features.check_with_template( low_latency = vm.features.check_with_template( 'audio-low-latency', low_latency) if low_latency:
Hi, I tested i on a slower computer and I have the same issue as you. Should check if there is a github issue already created for this, and if not, create a new issue on github
Thanks for the guide!
I’ve got it mostly working on 4.2 RC4 with the unrecommend policies on a sys-audio I also use as sys-usb. If I start a vm sound works and the vm shows up in pulse audio controller. However, if I have to restart the vm, for example to update the vm, sound won’t work and I get this error.
If I restart my entire qubes system audio will work again for all my vm’s the first time I boot them.
I’ve tried to restart pipewire with
systemctl --user restart pipewire
and restarting the daemon with
Those commands seem to kill sound for all my vm’s though.
Anyone else have this issue? For now I’m just restarting my entire qubes system to get sound back periodically.
For what it’s worth, this is working for me with Debian instead of Fedora on a virgin Qubes 4.2 rc5.
I still don’t know about the “host is down” problem with Fedora. It could be that I messed something up in the past because I’ve tried other guides before this one (but basically this was the same version, 4.2 with the latest updates).
I didn’t check mic or bluetooth yet.
I didn’t have the time figuring out the exact steps patching qubes-core-admin-client, though.