USB device stuck on same controller as everything else

(Framework 13 - 12th Gen - i7-1280P - 64GB RAM - Windows 11 23H2)

I’m trying to optimize the performance of a high-end external USB audio interface (RME Fireface UFX II), lowering the buffer size and latency as much as possible to facilitate real-time music performance. The manufacturer recommends attaching the device to its own USB bus where its communication with the system won’t be interrupted by other USB devices [1].

I’ve disconnected everything except this audio device, and tested connecting it to each of the 4 ports on the laptop. In all 4 cases, Device Manager shows that it is attached to same controller as the fingerprint reader and bluetooth controller, while the 3 other USB controllers/routers have nothing attached. [2] The problem compounds as more devices are connected since many of them connect to the same controller.

Is there any way to connect this device to its own controller?


[1] (section 40.3 - ‘USB Audio’)

[2] screenshots for all 4 tests are all identical

The controllers you are seeing I believe are the ones directly built into the intel 1280P CPU. They aren’t additional USB hubs.
See Framework-Laptop-13/Mainboard/Mainboard_Interfaces_Schematic_12th_Gen.pdf at main · FrameworkComputer/Framework-Laptop-13 · GitHub

The fingerprint and bluetooth adapter are not devices that use a lot of bandwidth. And note that they are just USB 2.0 devices, which is a hard limit on what they can use.

Also, do you plan to use them while recording? If not, then they won’t be in use at all.

It’s important to think about the actual devices here, if they will be in use and their abilty to use bandwidth.

Thanks for your reply. You are correct that those are not additional hubs. As described in the experiment, everything is unplugged except the audio device so no external hubs would be connected.

The goal is to get the audio device connected through one of those empty USB controllers shown in Device Manager so that other devices won’t interrupt its low-latency audio data flow.

Bandwidth is not the concern, generally. Latency is the concern. Even devices that don’t use much bandwidth (like a bluetooth mouse) still create interruptions when they communicate through the same controller. When the audio device is forced to share a controller with other devices that make small interruptions, the audio has clicks and pops. The only way the audio device driver can protect against this is by increasing the audio buffer which increases latency. Larger latency means a longer delay between pressing a note on a midi keyboard and hearing the sound come out of the audio device, which feels unnatural.

There are only 2 USB3 controllers. 1 in the chipset die, that the Framework uses only for USB2. And one in the CPU that only powers all of the USB3 functions of the TB4 ports. And since the FW only has TB4 ports, their USB3 functions all come from the shared USB3 controller in the CPU die.

1 Like