Hi everyone,
I'm new to this mailing list and have never done anything like this before, so I hope I'm following protocol and stuff! If you need any info that I don't provide here, I'm happy to provide it, but I'll do my best to provide all the information I've got in this email (which may make it quite a long one, sorry!). If this isn't the right list and I should send this elsewhere, let me know, though I felt this might be the most appropriate list to go to since it may be an audio device but I feel this is much more of a USB problem than anything else. I'm not subscribed to the list, so please CC any replies.
I recently acquired a Universal Audio Apollo Solo USB audio interface and am curious about getting it to work with Linux. There are no official drivers, but I'm hoping that we can at least get the audio interface part of it working. The Apollo Solo is a professional audio audio interface with an onboard DSP engine and audio interface. It doesn't quite conform to the UAC, but it does present input/output/clock source terminals via audio class descriptors. Or, rather, it does... On Windows, anyway.
And this is where everything gets confusing, so I hope I'm explaining everything properly.
When the device is plugged into a machine that doesn't have Universal Audio's special drivers installed, it presents itself as a Cypress WestBridge, vendor ID 2b5a and product ID 000c. However, when the drivers are installed, the drivers do something I'm struggling to identify to "boot" the device and many things change. When it's in it's "special boot mode" (or whatever you'd like to call it) it runs at USB 2.0 speeds and presents a significantly different device descriptor:
bLength: 18
bDescriptorType: 0x01 (DEVICE)
bcdUSB: 0x0200
bDeviceClass: Device (0x00)
bDeviceSubClass: 0
bDeviceProtocol: 0 (Use class code info from Interface Descriptors)
bMaxPacketSize0: 64
idVendor: Unknown (0x2b5a)
idProduct: Unknown (0x000c)
bcdDevice: 0x0100
iManufacturer: 1
iProduct: 2
iSerialNumber: 3
bNumConfigurations: 1
However, when it's booted, the device descriptor is:
bLength: 18
bDescriptorType: 0x01 (DEVICE)
bcdUSB: 0x0320
bDeviceClass: Miscellaneous (0xef)
bDeviceSubClass: 2
bDeviceProtocol: 1 (Interface Association Descriptor)
bMaxPacketSize0: 9
idVendor: Unknown (0x2b5a)
idProduct: Unknown (0x000d)
bcdDevice: 0x0000
iManufacturer: 1
iProduct: 2
iSerialNumber: 3
bNumConfigurations: 1
Through careful analysis of the firmware (which ships with the drivers and doesn't need us to dump it manually), I believe the onboard board is a Cypress (now Infineon) EZ-USB 3.0 FX3, hence Linux identifying it as a "Cypress WestBridge". The MCU is an ARM processor, though I am not certain which ISA revision it uses.
When plugged in and in it's boot mode, Linux is able to extract the first device descriptor above, but is unable to enumerate the device:
[ 61.091703] usb 3-3: new high-speed USB device number 4 using xhci_hcd
[ 61.299491] usb 3-3: New USB device found, idVendor=2b5a, idProduct=000c, bcdDevice= 1.00
[ 61.299502] usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 61.299505] usb 3-3: Product: WestBridge
[ 61.299508] usb 3-3: Manufacturer: Cypress
[ 61.299510] usb 3-3: SerialNumber: 0000000004BE
[ 66.674005] usb usb2-port1: attempt power cycle
[ 75.107555] usb usb2-port1: unable to enumerate USB device
If I try to force-bind the driver, this of course fails:
[ 220.383312] usbcore: registered new interface driver snd-usb-audio
[ 257.877076] usb 3-3: cannot find UAC_HEADER
[ 257.877401] snd-usb-audio: probe of 3-3:1.0 failed with error -22
However, when plugged in and I'm booted into Windows, and then I reboot into Linux without powering off the device (such that it remains in it's normal mode that Windows sets it up in), the snd-usb-audio driver is able to enumerate the device but can't figure out the sample rates:
[ 100.447871] usb 2-1: reset SuperSpeed USB device number 2 using xhci_hcd
[ 100.464845] usb 2-1: LPM exit latency is zeroed, disabling LPM.
[ 100.467241] usb 2-1: parse_audio_format_rates_v2v3(): unable to retrieve number of sample rates (clock 128)
[ 100.467444] usb 2-1: parse_audio_format_rates_v2v3(): unable to retrieve number of sample rates (clock 128)
[ 100.467798] usb 2-1: parse_audio_format_rates_v2v3(): unable to retrieve number of sample rates (clock 128)
[ 100.468047] usb 2-1: parse_audio_format_rates_v2v3(): unable to retrieve number of sample rates (clock 128)
[ 100.468249] usb 2-1: parse_audio_format_rates_v2v3(): unable to retrieve number of sample rates (clock 128)
So, what I crucially couldn't figure out -- and what I still don't precisely know -- is what Windows does that Linux does not which causes the device to boot up and present itself appropriately as a USB audio device, at least basically. Obviously it still requires quite a bit of manual tuning, but I feel like if we can figure out how it's initialized and configured we could get USB audio IO working -- and that's all I care about right now. >From what I could tell the USB audio interface is interface 1 (x-x:1.1), and the DSP engine is interface 0 (x-x:1.0).
Via repeated tries and lots of time, I've managed to set up a VirtualBox VM that I then installed Windows on and then the drivers. Though this VM doesn't fully identify the device as a UAC-conforming device (that is, it doesn't show up as an audio device but does get initialized), I have the packet captures from my windows install that I'll provide below for that part (switching to it as the default audio device, selecting sample rates and so on). I've managed to capture at least 3 captures of USB data, but all of them have over a thousand frames, which makes straightforward analysis difficult for me. It doesn't help that I'm not very good at this to begin with, though I'm learning as best I can. Though I am not positive all of the files I'll provide will be useful, I thought providing more data than was actually needed would be better than being overly conservative and not providing enough. Thus, this file (https://cloud.the-gdn.net/s/Kxme36mogoGFrWr), hosted on my nextcloud instance, has the following files:
- All the packet captures I have, with one being just a quick connect-forward-init sequence, one being a connect, forward-to-vm and then a wait for quite a while because I was installing the drivers (though they may not be all that desimilar), and one being the packets that USBPcap was able to get on my windows install, though I'm not positive how helpful that will be;
- A folder containing all drivers for UAD software;
- A folder containing an assembly language dump of the uausbaudio.sys driver, which I (believe) is what does this sequence, though I may be wrong; and
- A folder containing all the firmware for all of the devices in the UAD Apollo family, for both the initial firmware, update firmware, and firmware for the DSP engine.
The main directories that I think are important are:
- asm-dump
- captures
- Drivers/audio/usb/x64/win10
- Firmware/USB
I think the stuff related to UAD-2 are for the DSP engine and not all that relevant (but maybe it is relevant and I might be dismissing it out of hand, I don't know). The capture files are:
ua-init-short: this was when I'd plugged in the device and told VirtualBox to plug the device into the VM and capture it's USB data. After Windows initialized it, I immediately unplugged it.
ua-init-long: This file contains the packets from when I plugged in the device into the VM and began capturing it. Specifically, Windows set up the device as it does with any PNP device, and I obtained the drivers and installed them, and during that installation process the device was initialized.
ua-init-windows: This capture contains the data I was able to get from the USBPcap side of things. I had Windows running natively with the drivers installed, so I started capturing, plugged in the device, and let Windows fully initialize the device, including switching to it as the default audio device.
I know that this is a long message and will probably take a while to figure out, but I know I'm not the only one who's wanted to get these devices even preliminarily working on Linux, and I'm happy to assist and help in any way I can. I'll end this message here since it's getting quite long, but I hope something can come of all this, and again, sorry for the (really) long message!
Signed,
Ethin D. Probst
Sent with Proton Mail secure email.Attachment:
publickey - ethindp@pm.me - 0x846BFA7B.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
