[Fixed] Linux: USB Overflows

AlbertA

Fractal Fanatic
I've been using the Axe-FX II as a sound card in linux (Ubuntu 16.10 currently). One of the issues though I'm seeing though is overflows (not underflows) regardless of USB BUFFER size in the axe-fx.

Overflow artifacts are harder to spot it seems but I do hear clicks and pops now and then.

Does linux even do clock adaptation for UAC2?

Artifacts are clearly heard when playing a 1KHz sine wave.

Edit: I've fixed this on the linux kernel, and it's included in the 4.9 LTS release, 4.10 and above.

Edit: See http://wiki.fractalaudio.com/axefx2/index.php?title=USB#Linux
 
Last edited:
When I hear clicks and pops in my Axe, the first thing I look at is how much CPU my preset is eating up.
 
Ok, so dumping the Axe-FX II USB descriptors...I see the Axe uses asynchronous mode but has implicit feedback. Are there any other products with this configuration?
 
When I hear clicks and pops in my Axe, the first thing I look at is how much CPU my preset is eating up.

Empty preset. CPU less than 10% according to Utility menu.

The artifacts are subtle, but clearly Axe-FX II is saying host is causing overflows (i.e. it's not correctly adjusting how many samples it sends per usb frame)
 
Ok, so a brief cursory read of the USB2 audio class 2 and spec, implicit feedback is used since the axe-fx also provides endpoints for input and you can use those to derive the data rate, instead of providing an explicit feedback endpoint.

The spec says:
"However, exactly how the desired data rate F f is derived from the data rate of the implied
feedback endpoint is implementation-dependent."

I guess that's the crux of the issue.
 
Ok, so a brief cursory read of the USB2 audio class 2 and spec, implicit feedback is used since the axe-fx also provides endpoints for input and you can use those to derive the data rate, instead of providing an explicit feedback endpoint.

The spec says:
"However, exactly how the desired data rate F f is derived from the data rate of the implied
feedback endpoint is implementation-dependent."

I guess that's the crux of the issue.

Correct. The Linux driver is responsible for deriving the correct data rate by counting the number of samples received on the IN endpoints. It's difficult to do and requires a software PLL and SRC.
 
I think I found the issue... the driver is not setting a sync end point, so there's no implicit feedback at all, which actually explains why it never recovers until you reset the stream.

I believe the software PLL/src must be handled by ALSA already - I mean there's USB asynchronous DACs out there already claiming to work perfectly with linux.

In any case, it seems like there's a quirk method called that manually adds the sync end points for some USB Ids: https://github.com/torvalds/linux/blob/master/sound/usb/pcm.c#L316

Maybe I should try that...

Which end point should the implicit feedback come from?
 
Ah looks like 0x86:


Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x86 EP 6 IN
bmAttributes 37
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Implicit feedback Data
wMaxPacketSize 0x0054 1x 84 bytes
bInterval 1
 
I think I found the issue... the driver is not setting a sync end point, so there's no implicit feedback at all, which actually explains why it never recovers until you reset the stream.


giphy_zpsgzvqxbft.gif
 
I see the original issue is snd_usb_audio is expecting both endpoints to be on the same interface descriptor
 
I just made a comparison between Windows 10 and Ubuntu 16.10, same software (Pianoteq), same hardware.

Windows 10 using ASIO, USB driver set to minimal latency, ASIO buffer size set to 64 samples and Axe-FX USB BUFER SIZE set to 64 - I get a bunch of under-runs (clicks and pops galore).

With Linux, ALSA also set to 64 samples, USB BUFER SIZE set to 64 , just clean no issues :) And that's before even using a lowlatency kernel or giving RT thread priority permissions to the app.... excellent!
 
Awesome.

Dunno how they are going to react to a device specific patch tho.

Finger crossed here.
 
Back
Top Bottom