Setting up an audio VM

It’s the same behavior that is implemented with network vms, that’s why I would expect this.

I can provide instructions later in the next week.

4 Likes

Any news on this topic?

Unfortunately no, I’m currently busy with prior tasks.

For those that might stumble upon this thread in search for a solution for using bluetooth headphones with Qubes, I solved this temporarily by purchasing a bluetooth adapter into 3.5mm audio jack. Just make sure to get one that supports TX mode, like this one

So I got myself an audio-vm using

qubesctl state.sls qvm.sys-audio

removed pci-devices, set it’s audiovm to None (because the system would freeze on starting sys-audio and I think that was because of circular audiovm definitions?)
I installed qubes-audio-daemon from qubes-vm-*-current-testing

When I start a Qube which has audiovm set to sys-audio and run

pactl-simple-vchan [xl-id] [name]

I get an audio-stream which is visible in pavucontrol and, as pci-devices where still connected, audible.

My main usecase is using usb-audio and bluetooth without any touching dom0. When I connect my usb-headset to sys-audio, it is correctly detected and shows up in pavucontrol. However, when I use pactl-simple-vchan, I hear nothing. pavucontrol shows audio playback via the headset (the sound-bar jumps back and forth).

Even weirder, starting playback inside sys-audio works perfectly fine and keeps on working if I start pavucontrol while playback is audible.

Am I missing some pulseaudio/alsa/modprobe setup?

Just got this working.

Roughly the steps that I can recall now were to download the template vm that the sys-audio salt state uses - the salt states can be found here btw:

and fedora-33-xfce is the template vm it uses.

Once the state is run and the sys-audio vm created the template vm needs to have the qubes-core-admin-client rpm installed - this provides the qvm-start-daemon python script that is used to start the pacat processes for each vm audio client.

Next, startup the sys-audio vm and create ~/.config/autostart entries for qvm-start-daemon and pulseaudio:

eg. ~user/.config/pulseaudio.desktop
[Desktop Entry]
Name=Pulseaudio
Comment=Starts Pulseaudio
Icon=qubes
Exec=pulseaudio
Terminal=False
Type=Application
NotShowIn=KDE;

eg. ~user/.config/qvm-start-daemon.desktop
[Desktop Entry]
Name=Qubes Guid/Pacat
Comment=Starts GUI/AUDIO daemon for Qubes VMs
Icon=qubes
Exec=qvm-start-daemon --all --watch
Terminal=False
Type=Application
NotShowIn=KDE;

Next there are some problems with the policy that the salt state creates. It’s a bit of a pain to work though but the popup notifications are helpful - the policy is defined in /etc/qubes/policy.d/50-sys-audio.policy on dom0

I’d paste it here but tbh I’m a bit lazy and it’s on dom0 :stuck_out_tongue:

Finally, each vm needs to have the audiovm adjusted w/

eg. qvm-prefs audiovm sys-audio

2 Likes

Oh yeah, and I went into services on sys-audio and added the audiovm services.

Oh, and those .desktop files are in ~user/.config/autostart

Thanks for the instructions, I will try and post my results here.

Edit: I got a working audioVM, after a lot of troubleshooting and banging my head against a wall.
I will try to optimize the process and will post clearer instructions here when I have the time.

1 Like

I was able to run the salt formula and create sys-audio.

I successfully had sys-audio handling my soundcard, but I cannot create pulseaudio streams to it.
I used pacat-simple-vchan (dom-id of sys-audio) sys-audio in appvms, and most of them said command not found.

So I installed qubes-audio-daemon in my templates of my appvms. Now the command could be run, but nothing happened. No new “Application” stream in sys-audio. After I set qubes-prefs default_audiovm sys-audio, newly created qubes didn’t created streams in dom0, but not in sys-audio either, even after I had rerun pacat-simple-vchan.

So could anyone help me please? Thanks in advance.

1 Like

Update:Now I’m able to see virtual streams in sys-audio pulseaudio control panel.

However, playing songs is impossible because the pulseaudio doesn’t automatically update the sound buffer. I made this guess because everytime I click at any botton of the pavucontrol window, the sound will update a bit and replay that bit again and again(making a lot of noise). As long as I click quick enough, I can tell from the rather scratchy and intermittent sound that the song is being played.

So how can I fix that? Thanks.

There’s an error message when starting pulseaudio.

E: [pulseaudio] bluez5-util.c: GetManagedObjects() failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

So this might be the problem.

idk if you launched the pacat processes in the sys-audio vm… They are the processes that receive the audio streams from the other vms and they’re normally started by the qvm-start-daemon --all --watch command in the sys-audio vm.

w/ scratchy audio it kind of sounds like a buffer issue. There are a lot of posts out there about adjusting the pulse audio configuration to suite the audio hardware. iirc it’s mostly getting the buffering configured properly so playback is smooth. One fellow wrote a formula on how to calculate the buffer settings from lspci and other command output.

I had exact same problem with ‘scratchy’ sound. Was able to trace it down to audio qube first and then to sound card there falling asleep.

To fix this I created /etc/modprobe.d/liteqube.conf (you can use any mane ending with .conf) in template qube and put one line there:

options snd_hda_intel power_save=0
1 Like

As a newbie, I had to gather information and found it could be useful to summarize the steps to make it easier for others to repeat. Some steps might be not necessary.

  1. The Salt script will create sys-audio based on fedora-34-xfce. I didn’t have it installed, so decided to do it
    sudo qubes-dom0-update qubes-template-fedora-34-xfce
    Maybe it is not necessary and Qubes would select the default template (fedora-34) if it was not installed.

  2. In dom0:
    sudo qubes-dom0-update qubes-audio-dom0
    In the TemplateVM for sys-audio (fedora-34-xfce):
    sudo dnf install qubes-audio-daemon qubes-core-admin-client
    This is necessary to get the qvm-start-daemon command in the sys-audio VM.

  3. Don’t know exactly if it was needed to download the sys-audio.sls and sys-audio.top to /srv/pillar/base/qvm. I did it since haven’t seen those files there. Used the command to copy the files downloaded from github to src-vm to dom0:
    sudo qvm-run --pass-io <src-vm> 'cat /path/to/file_in_src_domain' > /path/to/file_name_in_dom0

  4. Run the salt script to create the sys-audio VM
    sudo qubesctl state.sls qvm.sys-audio

About the policy errors, I got some when I’ve tried running qubesctl before installing the fedora-34-xfce template. Then I removed the created sys-audio qube and the /etc/qubes/policy.d/50-sys-audio.policy file, run the steps above and then the qubesctl command run without errors. I have not investigated further.

After running this, I rebooted and got policy errors when starting qubes. I’ve added the following lines to file /etc/qubes/policy.d/50-sys-audio.policy and got rit of them:

admin.vm.feature.CheckWithTemplate  +audio-model   sys-audio     @tag:audiovm-sys-audio  allow   target=dom0
admin.vm.property.Get               +keyboard_layout sys-audio     @tag:audiovm-sys-audio  allow   target=dom0
admin.vm.property.GetAll * sys-audio	sys-audio	allow	target=dom0
admin.vm.property.GetAll * sys-audio	@adminvm	allow	target=dom0
admin.vm.property.GetAll * sys-audio	@tag:audiovm-sys-audio	allow	target=dom0
  1. In sys-audio settings, open Services tab and add the audiovm service (a custom service).

  2. In dom0, run the commands to assign sys-audio as its audiovm.
    qvm-prefs <targetVM> audiovm sys-audio
    One can also use this one to set sys-audio as audiovm for all other vms:
    qubes-prefs default_audiovm sys-audio

  3. Run sys-audio VM and create the files inside ~/.config/autostart folder

 ~/.config/autostart/pulseaudio.desktop
[Desktop Entry]
Name=Pulseaudio
Comment=Starts Pulseaudio
Icon=qubes
Exec=pulseaudio
Terminal=False
Type=Application
NotShowIn=KDE;

 ~/.config/autostart/qvm-start-daemon.desktop
[Desktop Entry]
Name=Qubes Guid/Pacat
Comment=Starts GUI/AUDIO daemon for Qubes VMs
Icon=qubes
Exec=qvm-start-daemon --all --watch
Terminal=False
Type=Application
NotShowIn=KDE;
  1. Fix sound. So now I could see in the sys-audio pavucontrol the streams coming from other qubes, their sound bars are jumping when playing something in other qubes and stop that when I stop playing. But no sound was coming out. Audio playback started in sys-audio also do not produce any sound (tried both youtube videos or with aplay /usr/share/sounds/alsa/...). I have tested with headset plugged in and out.

In dom0, I created a file /etc/modprobe.d/50-alsa.conf and audio started working after rebooting:

options snd_hda_intel enable=1 index=0 power_save=0
3 Likes

What I couldn’t make it work is the mic. When trying to attach the mic to a vm, I get the following error in a popup:

QubesVMError: Failed to attach audio input from sys-audio to <vmname>: pulseaudio agent not running.

Skip this step due to qvm.sys-audio has been in the state.sls

I am getting the same error. I only have a limited understanding of how Qubes works under the hood, but when watching journalctl in sys-audio while trying to attach the mic to a vm the following error is thrown:

sys-audio qubes.AudioInputEnable+[vmname]-dom0: socat E connect(5, AF=1 "/var/run/qubes/audio-control.[vmname]", 40): No such file or directory

When reading the Audio Virtualization Documentation these locations are mentioned as UNIX sockets which enable the audio input of a vm.
When running the pacat-simple-vchan command in sys-audio the following message is displayed:

Another instance of pacat-simple-vchan is already running for this VM

Could it be that the pacat-simple-vchan instances are supposed to create the UNIX sockets but for some reason don’t and so the qvm-device mic attach [vmname] dom0:mic command is not able to enable the vm for audio input, and if so is there a possibility create the socket or QubesDB entrance manually?

1 Like

I guess this fixs the problem.

Also feel free to look at my experience for reference if anyone is still having problem about sys-audio:

1 Like