USB Audio device passthrough

[otoman]

Hello,

I've been trying to create a VM for audio editing/production and so I've been trying to passthrough my Focusrite Scarlett 2i2 audio interface to it. Since I've been passing through GPUs and other devices without any apparent issues, I thought this would be an easy job. However, when I passthrough the USB device (be it via ID or Port), audio is terrible, laggy, glitchy and generally unusable.

The VM is Win 10 x64 with installed Focusrite drivers. When VNC-ing into VMs (like what I'm doing to write this), the VNC client passes audio to any connected device without problems. Of course, that signal is compressed and has latency so I can't do audio work with it. After some Googling around, I found a thread which says it's best to passthrough the entire controller via PCI passthrough. Now I have a problem - I can't find which PCI device is the hub for this particular USB port. I've tried lsusb with -t and -v arguments and I know which Bus and Port the device is on but I have no idea how to discern the PCI device related to it.

Is it even possible to do this without buying an additional PCI USB controller?

This is the output from usb-devices:
T: Bus=01 Lev=02 Prnt=04 Port=03 Cnt=03 Dev#= 37 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 2
P: Vendor=1235 ProdID=8016 Rev=01.ec
S: Manufacturer=Focusrite
S: Product=Scarlett 2i2 USB
C: #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=500mA
I: If#=0x0 Alt= 0 #EPs= 1 Cls=01(audio) Sub=01 Prot=20 Driver=snd-usb-audio
I: If#=0x1 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio
I: If#=0x2 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio
I: If#=0x3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)

I only pasted the part with the audio interface. I have no idea what most of this info means.
This is what lsusb -t produces:
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/9p, 20000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/16p, 480M
|__ Port 6: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 9: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 6, If 0, Class=Mass Storage, Driver=usb-storage, 480M
|__ Port 3: Dev 30, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 4: Dev 37, If 0, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 4: Dev 37, If 1, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 4: Dev 37, If 2, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 4: Dev 37, If 3, Class=Application Specific Interface, Driver=, 480M
|__ Port 10: Dev 28, If 2, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 10: Dev 28, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 10: Dev 28, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 11: Dev 7, If 0, Class=Human Interface Device, Driver=usbhid, 12M

Output of lspci:
00:00.0 Host bridge: Intel Corporation Device 4668 (rev 02)
00:01.0 PCI bridge: Intel Corporation Device 460d (rev 02)
00:02.0 VGA compatible controller: Intel Corporation AlderLake-S GT1 (rev 0c)
00:06.0 PCI bridge: Intel Corporation Device 464d (rev 02)
00:0a.0 Signal processing controller: Intel Corporation Device 467d (rev 01)
00:14.0 USB controller: Intel Corporation Device 7ae0 (rev 11)
00:14.2 RAM memory: Intel Corporation Device 7aa7 (rev 11)
00:15.0 Serial bus controller [0c80]: Intel Corporation Device 7acc (rev 11)
00:15.1 Serial bus controller [0c80]: Intel Corporation Device 7acd (rev 11)
00:15.2 Serial bus controller [0c80]: Intel Corporation Device 7ace (rev 11)
00:15.3 Serial bus controller [0c80]: Intel Corporation Device 7acf (rev 11)
00:16.0 Communication controller: Intel Corporation Device 7ae8 (rev 11)
00:17.0 SATA controller: Intel Corporation Device 7ae2 (rev 11)
00:19.0 Serial bus controller [0c80]: Intel Corporation Device 7afc (rev 11)
00:19.1 Serial bus controller [0c80]: Intel Corporation Device 7afd (rev 11)
00:1c.0 PCI bridge: Intel Corporation Device 7ab8 (rev 11)
00:1c.2 PCI bridge: Intel Corporation Device 7aba (rev 11)
00:1f.0 ISA bridge: Intel Corporation Device 7a84 (rev 11)
00:1f.3 Audio device: Intel Corporation Device 7ad0 (rev 11)
00:1f.4 SMBus: Intel Corporation Device 7aa3 (rev 11)
00:1f.5 Serial bus controller [0c80]: Intel Corporation Device 7aa4 (rev 11)
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Hawaii PRO [Radeon R9 290/390]
01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Hawaii HDMI Audio [Radeon R9 290/290X / 390/390X]
02:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd Device a809
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05)

Any help would be greatly appreciated.

My specs just in case:

CPU: I7 12700
RAM: 4x32 GB DDR4
MB: Gigabyte Z690 UD DDR4 (firmware 7a)
Additional GPU: Sapphire radeon R9 290 4GB
NVME: Samsung EVO 970+ 250 GB
HDD: 4x 8 TB WD GOLD

Thanks in advance!

 

[leesteken]

USB passthrough is indeed not good for high bandwidth or latency sensitive devices, as threads on this forum will show.
If you have a USB controller that is alone in a IOMMU group, you can use PCIe passthrough. You'll find out which physical ports are connected to it by seeing the device appear in the VM instead of the host.
I see only one USB controller in your lspci provided by the chipset, so this might not be ideal. Finding a good USB controller add-in card can be tricky (search for USB and VFIO on the internet to find one that resets properly) and your motherboard must provide a PCIe slot that is in a separate IOMMU group (which can be tested by plugging in any PCIe card).

 

[otoman]

Thanks for the reply. I should mention that I have no audio issues when passing through my gaming headset via USB. Though I suppose it doesn't use ASIO so that might be it.

EDIT: Would something like a KVM switch work?

 

[promoxer]

What happens when you passthrough via USB? I'm using the solo and it does garble up when there is disk load, otherwise works quite nicely. I swapped from a 3 down to 1 meter USB cable, seems to help even better.

 

[otoman]

For me the audio was unusable. Everything was stuttering and sounded like it was severely bit-crushed and distorted. A friend had a VIA PCIe to USB card so I passed that through to the VM and it solved the issue. The card can't seem to return to host after VM is shut down but I have a ton of ports so that's no problem. I had to get a separate card since somehow all my USBs are on a single controller.

 

[Docop2]

Prox passing usb to vm, via prox itself is for convenience. yes having 1 controller for the whole thing did not help, but the only solution and proper way is to pass the usb ctrl to the vm. not : usb- ctrl, debian, prox, vm , win10 vm. And on cable, a usb10gb will give 10g under 1m and about 18% loss speed on a 2m. This is with the new cable that just started to appear 2 months ago on the market. before the limit was quite 30cm. (not talking about tb3 cable)

 

[zyghom]

so in short: forget good audio from USB DAC on proxmox - it will not be the quality one, right?

 

[promoxer]

I have near metal experience in passing guest audio to my focusrite on the host via VBAN

 

[zyghom]

I have good USB DAC that can do good DSD and so on, today I deliver the music to it via Raspberry and USB. I was thinking about getting rid of Raspberry and moving LMS to Proxmox but if the audio is going to be affected then no.

 

[otoman]

Audio works normally if you have a dedicated controller which you pass through. My motherboard has all of its ports on a single controller, so I had to get a PCIe USB 3.0 card which I then passthrough to the VM. Mind you, you need IOMMU and everything set up to do this. I've been having issues here and there on my everyday VM, but I suspect it to be a driver + screen reader issue as I didn't have any issues previously. I haven't restored my studio VM with the old driver so I can't verfiy, but generally you should be completely fine with passthrough if you pass a whole controller.

EDIT: In case the above is confusing - you need to passthrough a USB controller directly to the VM and then you plug your devices into ports controlled by it. That controller (like my PCIe card) will be unavailable to everything else, including the host while the VM is running.

I have near metal experience in passing guest audio to my focusrite on the host via VBAN

What's VBAN?

 

[promoxer]

https://vb-audio.com/Voicemeeter/vban.htm basically audio over the network

 

[promoxer]

for the record, my focusrite is connected to the onboard USB of a consumer MB

 

[otoman]

for the record, my focusrite is connected to the onboard USB of a consumer MB

I have a higher-end consumer mobo too. Just make sure you have a port you want to use on a USB controller different from others. I believe the command to view the tree is somewhere in the previous posts where it was kindly explained to me.

 

[promoxer]

Passing thru USB for audio is just too fragile for me. By not doing that, I skipped alot of problems.

 

[otoman]

Passing thru USB for audio is just too fragile for me. By not doing that, I skipped alot of problems.

Yeah, it can cause some headaches I suppose. Though I can't complain with my results. Aside from the issue with my screen reader (which also could be the new cable or a bad USB card) I can't tell the difference and I need ASIO to use inputs and outputs.

 

[otoman]

https://vb-audio.com/Voicemeeter/vban.htm basically audio over the network

What's your experience with lactency when recording/using ASIO in general with VBAN? How does the driver handle that?

 

[promoxer]

My focusrite uses built-in Linux drivers by Proxmox. My use case is just listening to music and short voice recordings as messages.

While I have no experience with ASIO as I never found the need for it (even before virtualization), I would say I'm sensitive to lags and there is none that I can detect. The only glitch is a few audible "clicks" when the machine as a whole is under load.

This is in comparison to what I will call garbled audio when passing thru USB.

 

[loiphin]

I stumbled upon this thread and am also having plenty issues with my Focusrite Clarett 4pre USB, and passthrough from my Arch host to a Windows 11 Guest.

Although I am using Arch, I am pretty sure its the all the same (VFIO, QEMU) inner workings.

Sound in the guest works for a few minutes up to say 30 minutes. Then suddenly I get distortion, a bit crushing effect, beeping or silence. If I select another audio interface and then choose the Focusrite again, it normally works for a short time again, but the problem quickly reappears.

I have used the Focusrite Clarett on both the motherboard USB controller, passed through as a PCIE device to the windows guest, as well as a dedicated Startech PCIE USB 3.0 Card (Renesas chipset) passed through. Both exhibit exactly the same issues. The Startech card is considered the gold standard for PCIE USB cards and passhthrough.. it wasnt cheap!

So I am convinced that the USB implementation that Focusrite uses is very sensitive to timings or something like that, and just wont work.

My workaround for now is that I have passed through my motherboards audio card (Realtek ALC4082) to the windows guest instead, and it has worked flawlessly. Its just a shame I cant use my Focusrite Clarett

 

[zyghom]

My workaround for now is that I have passed through my motherboards audio card (Realtek ALC4082) to the windows guest instead, and it has worked flawlessly. Its just a shame I cant use my Focusrite Clarett

my workaround is... Raspberry Pi 4 ;-)

 

[promoxer]

So I am convinced that the USB implementation that Focusrite uses is very sensitive to timings or something like that, and just wont work.

My understanding is that it affects all USB audio due to its single thread nature and not specifically to the Focusrite.