wolftune wrote:USB 3.0 is full duplex. So when class-compliant audio comes out for that, we should be set! Right?
Not sure what you're getting at here. The primary difference between usb 1.1, 2.0, and 3.0 are that each successive version can transfer data faster and more efficiently than the previous version.
But that's not the issue here. The issue here has nothing to do with latencies or audio dropouts under linux versus other systems. ie, It's not a data speed issue. Rather, it's about feature support (or lack of it under linux). For example, under Windows, my MOTU Ultralite shows up as a USB audio device, and every program can use it. On the exact same computer running linux, ALSA doesn't even recognize it's an audio device, and no audio program can use it. Why? It has nothing to do with whether the MOTU is attached to a usb 1.1, 2.0, or 3.0 port. It has everything to do with the fact the MOTU is not usb-audio compliant (neither version 1 nor version 2 usb-audio). To operate the MOTU, the OS must have a software driver that "speaks" MOTU's proprietary language. Windows has that. MacOS has that. Linux (ALSA) doesn't.
As another example, my EMU 1616M interface does 24-bit audio with DSP hardware effects such as compression, EQ, reverb, etc, under Windows. On the same computer running Linux, it can do only 16-bit, and all the DSP hardware effects are gone. Why? Again, it's not an issue with data speed. It's the fact that the Windows driver is fully featured -- written to control all the features of the card. But the Linux (ALSA) driver for the EMU 1616M? Well, to quote a comment in the driver source code, written by the author, it's "too much work to support 24-bit operation" and DSP configuration. So those features "disappear" under Linux. And of course, to really rub salt into the wound, someone cuts and pastes all that useless drek about editing config files into ALSA's "support details" page for the EMU 1616M, marks the device as "supported", and doesn't mention these limitations. After all, any enduser is going to peruse C driver source code to discover whether the hardware actually works, right?
As another example, at one point, certain M-audio usb interfaces did 24-bit sample resolution, and more than 2 audio channels, under Windows. But under Linux, they were limited to 2 chans 16-bit. Why? Because these interfaces speak 2 languages. One language is called "usb-audio 1.0 class compliant". When speaking this language, the device is limited to 2 chans of 16-bit 48 KHz. It's a limit of the language (ie, stream protocol). Lots of usb audio devices (including ones made by other manufacturers) happen to speak this rudimentary language. So a single, usb-audio 1.0 class compliant driver can support many manufacturers' models. But with such a generic driver, all are limited to 2 chans of 16-bit 48 KHz audio, even if some models technically can support better. Now M-audio thought "we designed it to do better, so let's make it possible". Because the "usb-audio 1.0 class compliant" language doesn't support better, M-audio designed their interfaces to also speak a second, proprietary language where it's possible to do, for example, 4 chans of 24-bit 96KHz audio.
So guess which language the M-audio Windows driver speaks? The second, full-featured language. Guess which language the M-audio Linux driver speaks (because it's not really an M-audio specific driver -- it's a typical "this is just gonna be quick and rudimentary so it supports a bunch of generic budget hardware at the most basic config" linux solution)? Yep.
Later, some ALSA dev went out and spent $80 to upgrade his 1990's sound blaster card to one of these cheap M-audio things. And then he added the second proprietary M-audio language to the generic ALSA usb driver. So now Linux supports better... for a couple M-audio interfaces. But there are other devices that have their own proprietary second languages to support better (and they all have Windows drivers that support this), but are left out in the cold under linux. And worse, ALSA's "support details" web pages may list them as "supported". But what's a person supposed to conclude about linux if he, for example, buys a $650 UsbPre2 touted as "linux supported", and then discovers it has the feature support of a $1 used Sound Blaster 16 audio card under linux?
Now there's an international committee to oversee all usb standards. These folks noticed the proliferation of all these secondary, proprietary audio languages, and they concluded "maybe we should update our own usb-audio compliant language to do better". And they did. Voila. Version 2.0 usb-audio. But it's a matter of too little, too late. (ie, The usb-audio group exhibited a lack of leadership). Just about every manufacturer whose interface does better already did his second language in the hardware, and wrote his Windows and MacOS drivers to support it. It's a lot easier/cheaper to just tweak the hardware/language/drivers as needed for new models, rather than replace all that work with 2.0 compliance. Of course, that will mean, as usual, what little proprietary support ALSA has will stop working with newer M-audio interfaces, and those will be back to 2 chan 16-bit. After all, that ALSA dev already blew his hobbyist music budget on his Fast Track Pro, and that $80 interface has to last another decade or two, so no one's updating the ALSA support. And want to bet that the ALSA M-audio support details page will omit this info, and once again mislead linux users about the real working state of linux audio support?
But here's where the iPad comes in. Yes the manufacturers have their proprietary Windows and MacOS drivers done, but not iOS drivers (nor Android drivers if that ever gets serious about audio). And since iOS already has a generic 2.0 compliant driver, a manufacturer won't have to pay for costly new driver development... if only he adds 2.0 hardware support. He won't do it for linux. But he very well may for iOS, because iPad customers don't spend just $80 every two decades. But linux will benefit because ALSA also has a generic 2.0 compliant driver (which I suspect is woefully untested, but perhaps may sort of work... typically with reduced functionality that may satisfy folks with $80 interfaces).
But even this is not a panacea for linux's lack of audio support. Note that 2.0 compliance allows a driver to set higher rates and bit resolutions, and more channels. But it doesn't specify, for example, DSP settings. So whereas your next $80 interface may miraculously support maybe 4 chans of 24-bit audio under linux, you'll likely find yourself still saying something like "Damn it, I still can't turn the reverb on or off like I can on Windows. And the ALSA support page still doesn't tell me useful stuff like that, but instead tells me how to edit a config file that doesn't exist because it's pretty much deprecated by pulse audio on most every distro". Useful that.
And that's what I meant in my quote to which you replied.
Usb 3.0 interfaces will have no bearing upon linux audio support.