Hi so followed troubleshoot and first time executing the cmd to remove the device as my issue was the same with the example my entire desktop shutdown.
Did it again didn’t shutdown, so I proceeded setuping the file and enabling it to execute every reboot and so I tried starting sys audio and gave same error so I thought no problem I will just execute same cmd again system crash and them became locked out of system due to the file config triggering after reboot each time.
I tripled checked everything constantly after the first error and only after it crashed realized that it would just keep crashing due to the file in place.
Had this happen yesterday with importing a backup of mine, the sys-net keeping the old device info which caused a crash and because it booted at start u know how that goes XD
Yea so third time setting up Qubes in under 24 hours due to something this.
You would throw no I would learn or at least realize.
Didn’t even do a backup of my newest setup so got to do all the minimal installs and setups as will as the many different templates for increased compartmentalization. XD
Why I attempted sys-audio was due to the fact that I could not see or figure out how to use Bluetooth with standard setup, trying to use bluetoothctl and isn’t done with the needed audio adjustment in the sys-audio simple doesn’t work. I’ve tried to my best ability.
My audio with the default configs was giving to many issues, the audio was keep cutting out, and never had such via my monitor and direct plugin to PC on ur more standard Linux dostro like Ubuntu, Tails, Kicksecure, etc.
Also in regards to the blueman manager I had tried refresh multiple times before, reinstalling bluesman, etc and would still fail to display.
Im running a highend desktop of the latest and best AMD GPU, 128 GB RAM DDR 5, and top rated AM5 Hardware.
Had to hope off of Qubes for whole 2 months made me home sick to say the least and why I’m trying to use it on my desktop this time because the hardware is perfect for it.
BIOS and firmware are both up to date on latest so the audio issue is the biggest one for me due to work and other commitments.
So I need to try and get that working.
Appreciate the help and thank you for always assisting. This is odd and can’t understand myself why the troubleshooting even lead to such issues.
Also regarding the Bluetooth how does one even identify which it is as all my USB and thunderbolt devices which is multiple has the same name and when sys-usb is running I cant see any indication of bluetooth which the motherboard does have.
The guide suggests to remove the offending device (0000:03:00.1 in your case) from dom0 so it won’t interfere with bus reset when you attach 0000:03:00.0 device to sys-net since both 0000:03:00.0 and 0000:03:00.1 share the same bus.
Check what 0000:03:00.0 device is, if it’s some critical device e.g. your GPU then obviously you can’t remove it from your dom0 or because it won’t work without it.
If it’s a critical device that you can’t remove from dom0 then you can’t use PCI reset for your audio device 0000:03:00.1 if you want to passthrough it do sys-audio.
In that case you can try to enable no-strict-reset for this device attached to sys-audio like this: PCI troubleshooting | Qubes OS
But using PCI device without resetting it may have some security issues as described in the link and here as well: Device handling security | Qubes OS
Are you sure that you’re installing it in a template of your sys-audio?
Try to run blueman-manager in the sys-audio terminal.
If it’ll start then search for the blueman-manager .desktop file in the system.
Post the output of lspci in dom0 and lsusb in sys-usb.
Thank you for the response.
Apologies for the delay took me a while to get everything setup again.
Yea 03:00.0 is the GPU and 03:00.1 is the audio for the HDMI/DP, I still don’t really entirely understand why the audio device can’t be assigned/used with another qube and some others with a GPU can hence the guide. I don’t get it why it is like this and on the other hand somewhat can see why. Its weird. Like I get the GPU in is assigned to Dom0 and that the audio/visual input and output is apart of it but I just dont understand why it cant be assigned and why some others can. I don’t have the sufficient to exact details on this subject matter with control and devices.
Yes I installed blueman in the template.
Yea the lack of reset is concerning but like I said I somewhat understand why but don’t to the greatest exacts. However I don’t really need bluetooth its nice but never a must but rather the must is that I actually get constant audio with right now for some reason I just keep having these audio breaks and moments of no audio that could last as long as 5 minutes without a way to fix it where with other distros I don’t have this issue.
For now I think its best if I don’t have a sys-audio and wait for a more officially released method by the team cause it not really need unless one wants to use bluetooth.
Regarding that as well I still can’t seem to identify what specifically is the bluetooth device as it doesn’t necessary present is as clear cut in both outputs.
Any suggestions on the audio issue would be great.
Contrary to a GPU, the qubes are connected together to the one with the audio device using wireplumber to transport audio.
By default, dom0 is the audio server and use the screen or speakers to output sounds, as it owns the GPU it can do it over HDMI. All other qubes are connected to dom0 sound server to get the audio out.
With sys-audio, the audio device(s) must be owned by sys-audio, then dom0 can be used as an output for sys-audio to use speaker / HDMI audio.
Fixed an issue in the guide, the permission allowed by the policy file were too restrictive. Not enough privileges to correctly query the qubes.vm.List / qubes.vm.CurrentState API.
Thanks for this guide! I’ve hit a few issues, would appreciate any help!
Whenever I start a VM, I see a policy error - admin.vm,property.GetAll from sys-audio to [started vm] denied. Is this expected? I added the policies from the guide without any edit.
I can hear audio from a connected bluetooth headset, but can’t hear anything when I change to use the bulit-in speaker.
Is there a way to hide the dom0 audio tray icon, now that it doesn’t do anything, and is there a way to add those controls (the volume slider and mute) to the PulseAudio tray icon coming from sys-audio?
I found out that the actual identifier for such a device can change from one boot to the next. So I don’t do that; but that means I have to remember to explicitly map the device whenever I restart the system.
As an aside, I’m no longer using sys-audio. It still sometimes just quits accepting new client VMs, and if you stop and restart a client, it won’t actually reconnect, meaning I have to shut down ALL remaining clients to restart sys-audio. In addition to that, I believe the audio quality is lower. It’s simply not worth the trouble.
I have noticed that you can restart sys-audio from the Qubes Manager even if other qubes connected to it are running. It is kind of fun to see that audio playing from a qube stops and then continues once sys-audio is up and running again. But I agree that it would be good if qubes would reconnect to sys-audio on restart.
I have set up my sys-audio with a debian-12-minimal template, and I was getting an error when trying to connect the microphone to a qube (something along the lines of “pulseaudio agent not running”). It turns out that I was missing the ‘socat’ package in the qube. Once I installed it, the error was gone.
I just want to leave this written somewhere…
I tried creating an audioVM. It seems to work except I get a bunch of warnings when starting VMs after putting the policies in place about permission denied. I was getting audio output when I had pipewire-alsa, but I wanted to use pipewire-pulse instead… after switching I only have HDMI output devices available which I don’t use (I use display link that doesn’t have audio and headphones)… I’m not sure how to access the integrated audio devices within the audioVM? It can’t be passed like a USB device would so I’m not sure how to access it; although obviously the devices are available since it worked briefly with pipewire-alsa installed (although reinstalling pipewire-alsa alone didn’t get audio back). Within the pipewire Volume Control application, I can see recording devices (applications) that are sending audio the the audioVM, but I only have the HDMI devices listed as Output Devices.