Audio qube

solene · September 10, 2024, 2:29pm

I enabled the service bluetooth

glockmane · September 12, 2024, 8:31pm

Followed the complete guide passing 00:1f.3 Audio Device but it won’t get recognized, in Volume Control App from sys-audio I only see Dummy Output as Output Device… AX210 Bluetooth Device works…

Edit:

I think problem is IOMMU Groups, there are other devices in the same group which I don’t want to pass (like Ethernet)… I think using ACS Override would not be a good idea either… Am I right?

neowutran · September 15, 2024, 7:02am

You could need to configure the device in the Volume Control App. And the result of the command “sudo dmesg” could be usefull to understand if there is any issue. also did you installed the required driver for AX210 ?

neowutran · September 15, 2024, 7:05am

Added this part in the guide

neowutran · September 15, 2024, 9:21am

Regarding the post “Audio qube - #217 by QmanQtwo”, can other peoples confirm that it solved their issues by commenting, and if it solved the issue for Debian template or Fedora template ?

csnyder · September 17, 2024, 1:41am

I am so excited about this post. Thank you, @neowutran !

I am having some issues that in part - but don’t fully - resemble the challenges others have had.

So far I’ve been able to set up the three qubes with the same parameters from the qvm-prefs screenshots.

However, my sys-audio devices was different - only one audio device instead of two (it’s a Purism Librem 14). Did I do this correctly?

I did it in debian b/c for some reason fedora wasn’t creating disposable qubes for me. When I run this:

sudo apt install -y pipewire-qubes qubes-audio-daemon pavucontrol qubes-core-admin-client qubes-usb-proxy alsa-utils

I get the error messages:

The following information may help to resolve the situation:

The following packages have unmet dependencies:
 pipewire-alsa : Conflicts: pulseaudio but 16.1+dfsg1-2+b1 is to be installed
 pipewire-audio : Conflicts: pulseaudio but 16.1+dfsg1-2+b1 is to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.

Do I need to worry about this?

And then, if I try to start sys-audio, I get this error message:

Start failed: Requested operation is not valid: PCI device 0000:00:14.0 is in use by driver xenlight, domain sys-usb, see /var/log/libvirt/libxl/libxl-driver.log for details

Any suggested next steps? Many thanks.

apparatus · September 17, 2024, 6:15pm

csnyder:

I did it in debian b/c for some reason fedora wasn’t creating disposable qubes for me. When I run this:

sudo apt install -y pipewire-qubes qubes-audio-daemon pavucontrol qubes-core-admin-client qubes-usb-proxy alsa-utils

I get the error messages:

The following information may help to resolve the situation:

The following packages have unmet dependencies:
 pipewire-alsa : Conflicts: pulseaudio but 16.1+dfsg1-2+b1 is to be installed
 pipewire-audio : Conflicts: pulseaudio but 16.1+dfsg1-2+b1 is to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.

Do I need to worry about this?

Yes, you need to remove pulseaudio before installing pipewire.

github.com/QubesOS/qubes-issues

Both pulseaudio and pipewire installed

opened 08:52AM - 29 Dec 23 UTC

3hhh

T: bug P: major needs diagnosis C: audio affects-4.2

[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/) #…## Qubes OS release 4.2 ### Brief summary After a 4.1 to 4.2 upgrade I was surprised to find that both pulseaudio and pipewire were installed in both dom0 as well as debian-12. ### Steps to reproduce 1. Upgrade 4.1 to 4.2 as per official instructions. 2. Check dom0 and debian-12 template for pulseaudio or pipewire. ### Expected behavior One of the two is installed. ### Actual behavior Both are installed. In dom0 even both are running! I'm therefore not surprised anymore that my audio isn't working. ### Possibly related #8560 #8495

You have the same PCI USB controller 00:14.0 attached to both sys-audio and sys-usb. You can’t attach the same PCI device to the multiple qubes simultaneously.
You need to remove this controller from sys-usb or shutdown sys-usb before starting sys-audio.

glockmane · September 19, 2024, 10:29am

There is nothing to configure, no Audio device… Also AX210 is WiFi & Bluetooth… Bluetooth works in Audio Qube… I guess it is my IOMMU groups and could only be fixed with ACS Override, which I do not want cause it could introduce attack surface… So no Audio Qube for my Hardware

solene · September 19, 2024, 10:37am

My sys-audio sometimes start after some other qube using sys-audio as their audiovm, so they don’t have sound until I restart them.

How do people handle that? I don’t think there is a dependency tree on audiovm when starting the qubes.

vicent · September 21, 2024, 6:32pm

My audio-template is also debian based. I’ve installed both pulseaudio and pipewire. You say that pulseaudio must be removed before installing pipewire. But if I try to do it:

# apt remove pulseaudio
...
The following packages will be REMOVED:
  pulseaudio pulseausio-module-bluetooth qubes-audio-daemon
0 upgraded, 0 newly installed, 3 to remove and 0 not upgraded.
After this operation, 7038 kB disk space will be freed.
Do you want to continue? [Y/n]

So it is trying to remove qubes-audio-daemon which is a required package. Now I’m confused. Which packages should I install in audio-template?

apparatus · September 21, 2024, 6:55pm

I guess it’s a bug in the debian dependencies.
Based on this:

Does this affect in any way non Dom0 AudioVMs that have the package qubes-audio-daemon installed? Pulseaudio is still referenced in that package requirement.

pulseaudio-daemon is provided by pulseaudio but also by pipewire-pulseaudio.

Audio underruns in dom0 soon after uncorking stream · Issue #8955 · QubesOS/qubes-issues · GitHub

The qubes-audio-daemon package shouldn’t be a dependent on pulseaudio package.
At least it’s not like this for fedora:

$ dnf repoquery --requires qubes-audio-daemon
/usr/bin/sh
libc.so.6(GLIBC_2.38)(64bit)
libconfig
libglib-2.0.so.0()(64bit)
libpulse-mainloop-glib.so.0()(64bit)
libpulse-mainloop-glib.so.0(PULSE_0)(64bit)
libpulse.so.0()(64bit)
libpulse.so.0(PULSE_0)(64bit)
libqubesdb.so()(64bit)
libvchan-xen.so.1()(64bit)
pulseaudio-daemon
pulseaudio-libs
python3-pydbus
qubes-utils >= 3.1.0
rtld(GNU_HASH)

But for some reason it’s a dependence for debian:

$ apt info qubes-audio-daemon
Package: qubes-audio-daemon
Version: 4.2.8-1+deb12u1
Priority: optional
Section: admin
Source: qubes-gui-daemon
Maintainer: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Installed-Size: 60.4 kB
Depends: pulseaudio, libc6 (>= 2.34), libglib2.0-0 (>= 2.31.8), libpulse-mainloop-glib0 (>= 0.99.1), libpulse0 (>= 0.99.1), libvchan-xen1 (>= 4.2.0)
Breaks: qubes-gui-daemon-pulseaudio (<< 4.1.21~)
Replaces: qubes-gui-daemon-pulseaudio (<< 4.1.21~)

I guess this should be reported on the github.

vicent · September 22, 2024, 8:04am

Thanks for your answer. I’ve reported a bug as you suggested.

Mirai · October 8, 2024, 7:01pm

Just want to report back that it works a lot more reliably with a USB soundcard ( I don’t think I will ever use my integrated ever again even tho switching audiovms back and forth helps sometimes).

SteveC · October 13, 2024, 4:31pm

Well, after a ton of struggle last year…then giving up…I decided to revisit this.

One thing I changed in my hardware was to use a USB speaker rather than pulling the audio out of a HDMI splitter (my hardware has no audio jack). It’s entirely possible the reason I failed last time was trying to run it through HDMI.

Anyhow, I now have it working. A banner day!!!

One thing that may be missing from the instructions (I couldn’t find it) was having to set a tag for sys-audio: qvm-tags sys-audio add audiovm-sys-audio.

Without this, the policy won’t work because it’s looking for that tag. (I actually realized this before I tried running for the first time!)

solene · October 13, 2024, 4:44pm

My sys-audio does not have this tag.

neowutran · October 13, 2024, 6:17pm

Weird, you should have this tag. But you should not have to set it manually. I think

solene · October 13, 2024, 7:22pm

if that help

$ qvm-tags sys-audio
audiovm-dom0
created-by-dom0
guivm-dom0

neowutran · October 13, 2024, 7:26pm

Thanks, and nevermind, i just confused myself, the tag just indicate that you configured sys-audio to use dom0 as it’s audiovm

solene · October 13, 2024, 7:32pm

I did not change anything I never use qvm-tags, except to change the guivm (it’s a script to switch between dom0 and sys-gui-vnc)

neowutran · October 13, 2024, 7:37pm

The tag is automatically modified when you run qvm-prefs sys-audio audiovm dom0. The tag just mirror the value of qvm-prefs so it can be used in the policy file