[Linux] USB issue when powering on unit

I always had a similar problem with the AX8. I had the wait for the unit to fully power on before I could connect it to the computer, otherwise Fractal-Bot wouldn't see it. I've just followed the same protocol these days with the II and the III, but I can see where that would be a nuisance for anyone who keeps the unit connected to the computer. I'll have to experiment later and see if only certain combinations of power cycles and connections work. FWIW - I'm on a Mac.
I kept my II and I keep my III plugged into my Mac 24/7 and never have any issues with fractalbot or protools not recognizing the unit.
 
I'll have the engineer look at it but we don't support Linux nor do we have Linux machine available so I can't guarantee anything.

OK, I debugged further. The root cause is waiting for USB to set interface 1 to alt setting 1 (I guess basically enabling output Audio streaming). I presume the USB core won't do it until the DSP is ready to receive audio from it. In my case, the Axe-Fx 3 takes about 15 seconds to fully boot which is at the time USB finally acks that control message. The linux driver however has a 5 second timeout hardcoded in the core usb logic (https://github.com/torvalds/linux/blob/v4.17-rc1/drivers/usb/core/message.c#L1409) - the protocol errors I was seeing in the kernel logs were just an after the fact consequence of the timeout.

This explains the dependency on the loading screen I was seeing.

I suppose I can add a boot quirk in snd-usb-audio to work around it...but it would be easier if USB enumeration just happened after the system is fully booted up.
 
OK, I debugged further. The root cause is waiting for USB to set interface 1 to alt setting 1 (I guess basically enabling output Audio streaming). I presume the USB core won't do it until the DSP is ready to receive audio from it. In my case, the Axe-Fx 3 takes about 15 seconds to fully boot which is at the time USB finally acks that control message. The linux driver however has a 5 second timeout hardcoded in the core usb logic (https://github.com/torvalds/linux/blob/v4.17-rc1/drivers/usb/core/message.c#L1409) - the protocol errors I was seeing in the kernel logs were just an after the fact consequence of the timeout.

This explains the dependency on the loading screen I was seeing.

I suppose I can add a boot quirk in snd-usb-audio to work around it...but it would be easier if USB enumeration just happened after the system is fully booted up.
Open a pull request against the USB driver to make it a configurable time out?
 
Open a pull request against the USB driver to make it a configurable time out?

Heh.. there's no pull requests against the kernel... Linus will hate you if you do that. But one could sent a patch to the kernel mailing list :)

However, since this is in a core part of the usb logic, and countless devices have had no problem... I doubt a patch increasing the timeout or adding an api that takes a timeout value would be approved (since so far only a single device would need this).

But I can add a boot quirk in snd-usb-audio if it comes to that - at least there's precedent there for device specific quirks.
 
Heh.. there's no pull requests against the kernel... Linus will hate you if you do that. But one could sent a patch to the kernel mailing list :)

However, since this is in a core part of the usb logic, and countless devices have had no problem... I doubt a patch increasing the timeout or adding an api that takes a timeout value would be approved (since so far only a single device would need this).

But I can add a boot quirk in snd-usb-audio if it comes to that - at least there's precedent there for device specific quirks.
I didn't say increase the time out. :)
 
I wonder why the kernel specifically has a 5 second timeout. I would presume a number of USB devices could take a while to initiate.

I presume they were being generous. I suspect most devices enumerate when they are fully ready.
 
I presume they were being generous. I suspect most devices enumerate when they are fully ready.
I couldn't find any reference for an enumeration readiness requirement for USB-compliant devices so it's weird there's a 5s timeout imposed by the kernel. I'd expect a try-and-backoff strategy from the kernel here.
 
I couldn't find any reference for an enumeration readiness requirement for USB-compliant devices so it's weird there's a 5s timeout imposed by the kernel. I'd expect a try-and-backoff strategy from the kernel here.

Maybe USB 2.0 section 9.2.6.4 is applicable? It even mentions 5 seconds explicitly:

For standard device requests that require a data stage transfer to the device, the 5-second limit applies. This means that the device must be capable of accepting all data packets from the host and successfully completing the Status stage if the host provides the data at the maximum rate at which the device can accept it.
 
For now I'm working around the issue with this patch.

If you are using Ubuntu 16.04/xenial or 17.10/artful, you can use my PPA's snd-usb-audio-dkms package to workaround the issue described in the OP along with the overflow quirk fix described here.
 
Maybe USB 2.0 section 9.2.6.4 is applicable? It even mentions 5 seconds explicitly:
Yea, I think you're right.

The III is clearly fine once the controller is ready, it's that long boot before controller ready. There's either a very long timeout or a polling loop in Windows and macOS for this then because the long time to boot and get the USB controller ready doesn't seem to be a problem for either of those OSes.
 
Yea, I think you're right.

The III is clearly fine once the controller is ready, it's that long boot before controller ready. There's either a very long timeout or a polling loop in Windows and macOS for this then because the long time to boot and get the USB controller ready doesn't seem to be a problem for either of those OSes.

Yeah I suspect they just have a bigger timeout there or potentially better recovery if a timeout occurs. OR maybe they simply don't enable streaming right away after enumeration like ALSA wants to do.
 
Great work, pal!

I presume everything works great on Linux given that Axe Edit also works well under wine?

Thanks.

Yeah it works pretty well, other than this, which seems to be an issue at the Axe-Fx III side which happens with ALSA as well.

Thankfully I use JACK which just keeps the stream always active, so I only get that issue at the very beginning.
 
Back
Top Bottom