Open rapenne-s opened 1 year ago
@rapenne-s Can you try the “Audio VM” feature: qvm-prefs SOMEVM audiovm sys-usb
? That should be both more reliable and more secure than USB passthrough. To be clear, this is still a bug!
I did the following to be sure it's applied correctly:
qvm-prefs SOMEVM audiovm sys-usb
After a reboot, the prefs persisted, but I have no sound coming to any output of sys-usb, I monitored that using pavucontrol.
Extra note, in sys-usb pavucontrol, everything looked fine in input/output devices (in contrary to qubes receiving a device using usb passthrough)
In SOMEVM, do you have PulseAudio or PipeWire running? You can check with systemctl --user status pipewire.service
and systemctl --user status pulseaudio.service
.
user@Hangar ~> systemctl --user status pipewire.service
● pipewire.service - PipeWire Multimedia Service
Loaded: loaded (/usr/lib/systemd/user/pipewire.service; enabled; preset: e>
Drop-In: /usr/lib/systemd/user/service.d
└─10-timeout-abort.conf
Active: active (running) since Fri 2023-09-08 07:02:57 CEST; 1h 30min ago
TriggeredBy: ● pipewire.socket
Main PID: 600 (pipewire)
Tasks: 3 (limit: 4617)
Memory: 8.2M
CPU: 23ms
CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/pipewi>
└─600 /usr/bin/pipewire
sept. 08 07:02:57 Hangar systemd[591]: Started pipewire.service - PipeWire Mult>
user@Hangar ~> systemctl --user status pulseaudio.service
Unit pulseaudio.service could not be found.
Can you make sure pacat-simple-vchan
is installed in the AudioVM? If it is not present, audio won’t work in VMs that have that VM as AudioVM.
Can you make sure
pacat-simple-vchan
is installed in the AudioVM? If it is not present, audio won’t work in VMs that have that VM as AudioVM.
I don't have a command in $PATH with that name, neither an available package in fedora-38 when using dnf search pacat-simple-vchan
:thinking:
qubes-libvchan-xen.x86_64
is installed though, if this means something to you ^^'
@rapenne-s You’ll need qubes-core-admin-client
and qubes-audio-daemon
installed.
here is what I did:
is the test protocol ok?
why aren't these packages installed by default if they are used for the audiovm feature? :thinking:
@rapenne-s You will also need to enable the audiovm
service in sys-usb
and add a whole bunch of qrexec policies:
admin.Events * sys-usb sys-usb allow target=dom0
admin.Events * sys-usb @adminvm allow target=dom0
admin.Events * sys-usb @tag:usbvm-sys-usb allow target=dom0
admin.vm.CurrentState * sys-usb sys-usb allow target=dom0
admin.vm.CurrentState * sys-usb @adminvm allow target=dom0
admin.vm.CurrentState * sys-usb @tag:usbvm-sys-usb allow target=dom0
admin.vm.List * sys-usb sys-usb allow target=dom0
admin.vm.List * sys-usb @adminvm allow target=dom0
admin.vm.List * sys-usb @tag:usbvm-sys-usb allow target=dom0
admin.vm.property.Get +audiovm sys-usb @tag:usbvm-sys-usb allow target=dom0
admin.vm.property.Get +xid sys-usb @tag:usbvm-sys-usb allow target=dom0
admin.vm.feature.CheckWithTemplate +audio sys-usb @tag:usbvm-sys-usb allow target=dom0
Those come from /srv/formulas/base/virtual-machines-formula/qvm/sys-audio.sls
with sys-audio
replaced by sys-usb
, and you can (and should) regenerate them yourself rather than pasting from a GitHub comment (which you should not trust with complete control of your system). I think this also allows sys-usb
the ability to list all VMs on the system, which should be fixed at some point.
You might also need to change the PipeWire config in sys-usb
’s template so that the Qubes PipeWire module failing to load doesn’t cause PipeWire to quit.
Obviously, this is terrible, would make @marmarta (our UX person) cry, and really needs to be fixed.
I think this also allows
sys-usb
the ability to list all VMs on the system, which should be fixed at some point.
It allows only listing those with sys-usb as audiovm (which is necessary for it to function).
while a working audio-vm would be cool, I think we have a misunderstanding about the issue itself :sweat_smile:
I reported a regression in 4.2 compared to 4.1, now, passing an USB audio device to a qube doesn't work for all the three devices I tested, while it worked before :+1:
while a working audio-vm would be cool, I think we have a misunderstanding about the issue itself 😅
I reported a regression in 4.2 compared to 4.1, now, passing an USB audio device to a qube doesn't work for all the three devices I tested, while it worked before 👍
Yup, good point (which is why I filed #8504 for the other problems).
Plug in an USB headset (tested with a Dragonfly Black DAC and a Jabra Evolve 2), attach it to a qube there is no sound go in pavucontrol last tab and try to switch profile you may have sound, but maybe not microphone
I'm using a USB headset with a microphone, and both are working!
Here's what you need to do:
Check my reply to the ticket: https://github.com/QubesOS/qubes-issues/issues/8193#issuecomment-1626208571
So, just install pulseaudio-pipewire in the Fedora and Debian templates for now. And don't forget to attach the headset from the sys-usb icon in the taskbar to the intended VM, and then yoooppeeee, everything is working!
This is a temporary fix though, but thanks for sharing :)
https://github.com/QubesOS/qubes-issues/issues/8896#issuecomment-1960560934
Dropping this here hoping to help solve the issue. (how to make pipewire work in debian/fedora (minimal) templates)
How to file a helpful issue
Qubes OS release
4.2-RC2 and 4.2-RC3 (not tested RC1)
Brief summary
When I attach an USB headset / headphones, I don't have any sound, this used to work out of the box on 4.1.
If I run pavucontrol in the qube in which I attached the USB device, in the output devices there is only a qube virtual device. By fiddling with the last tab "Configuration" and switching the device to "pro audio" profile make it appear in the output devices and I can have sound.
In the case of a Jabra Evolve 2 headset which has two modes:
Steps to reproduce
Expected behavior
it works as it used to work on 4.1
Actual behavior
no sound