Support of audio interfaces under Linux

[wolftune]

Wow, Nicola, good persistent work. It's what I've been saying all along, but I didn't do the digging to be able to express it like this.
Cheers

[j_e_f_f_g]

There is no limitation to 16-bit in the usb audio 1.0 class specification. Jeff, now we could ask you: have you studied the USB 1.0 Audio Class specs?

Funny you should mention it, because after wolf reported his Alesis was doing 24-bit, and yet I found no entry in quirks_table.h or quicks.c of the ALSA usbaudio driver, that puzzled me. So, I went over to the usb org site, read the official spec, and discovered that the spec does indeed support 24-bit (and even 32-bit, if there ever was a need for it), and higher bit rates too.

But there's more to it than that. After all, there are devices that do 24-bit or/and high sample rates, but are limited to 16-bit 48KHz with the generic usb driver. I haven't finished going over the spec, studying ALSA's usb driver, and checking out other sources, but here's some things I've discovered:

There isn't a version 2 of the spec. There's only one version. I've seen many sources, including the ALSA dev mailing list, referring to "2.0 audio class compliant". This is a misnomer. I think what is meant is "audio class compliant in an interface designed for the usb 2.0 bus" (versus "audio class compliant in an interface designed for the usb 1.1 bus"). A 1.1 bus has really low bandwidth, so it's plausible that 1.1 devices had a "safe" practical limit of 16-bit 48KHz operation. But, I haven't found any such limitation in the spec itself. Wolf also mentioned a half-duplex limitation, but again, I see no such limitation in the spec. Usb 2.0 bandwidth will definitely accomodate multiple 24-bit tracks full duplex. If a particular 2.0 interface doesn't do that, it would have to a limit of the interface itself. It has nothing to do with class compliance.

The generic Usb Audio class driver for Windows does limit a device to 16-bit 48KHz. This is a limit in the driver itself. If a vendor wants more than that, it's expected that he'll take the DDK source, and create a driver for his product. So when a vendor says that his device is limited to stereo 16-bit 48KHz if you use a generic audio class compliant driver (instead of his proprietary driver), he probably means under Windows.

But... and here's a big but... not all devices fully implement class compliance. First of all, the device needs to report itself as an audio class device. Your alesis' device class (actually interface class) reports itself as a digital audio device. But some devices use generic usb controller chips that do not specify a particular class. Instead, the chip specifies a "vendor specific" class (255). For example, my Opcode Midiport actually is UsbMidi class compliant, but doesn't report that. So I just added an entry to quirks_table.h, recompiled the ALSA usbaudio driver, and now it works. Furthermore, the device needs to provide certain standardized descriptors that specify the supported rates, resolutions, and channels. Again, not all devices do this. Vendors don't care about providing this information because if the vendor is providing his own windows/mac drivers anyway, then obviously the driver knows what the device's capabilities are (without needing to be told by the device). You can buy third party usb chips that implement basic class compliance (ie like reporting just stereo 44/48 16-bit operation -- well nowadays 24-bit is getting common), but if you need more than that, you've got to resort to a programmable chip (ie, raises cost). Or, just go with a cheap generic usb chip, because it doesn't matter when you're providing the drivers. I haven't dug far enough into the ALSA drivers, but I suspect, when the device doesn't specify the descriptor's, ALSA may assume a common default of 16-bit 44KHz. ALSA has to assume something.

[posscakes]

Sorry i haven't read all of the posts just flicked through it quickly, but Jeff i can say this of Linux audio support i can think of a few people who seem to know a hell of a lot about ALSA, Jack, Ardour between them and so they ought to when you think about it, and get this man they seem to be pretty easy to contact through lists and what not. Now i'm not saying harass them about the state of the place but they might help you troubleshoot specific hardware if you ask.

[varpa]

I believe there are both USB audio standards class 1.0 and 2.0. Here is a webpage which describes both: http://www.thewelltemperedcomputer.com/KB/USB.html

[raboof]

Thanks for your balanced post!

some devices use generic usb controller chips that do not specify a particular class. Instead, the chip specifies a "vendor specific" class (255). For example, my Opcode Midiport actually is UsbMidi class compliant, but doesn't report that. So I just added an entry to quirks_table.h, recompiled the ALSA usbaudio driver, and now it works.

Cool. Have you notified the ALSA devs so they can include this improvement in the next version?

[j_e_f_f_g]

Have you notified the ALSA devs so they can include this improvement in the next version?

I'm subscribed to the ALSA dev list, and posted a patch to the list, but I don't think the email ever got through. Not sure what happened there. Here's what I added to quirks_table.c if you want to pass it on:

Code: Select all

/* Opcode devices */
{
   USB_DEVICE_VENDOR_SPEC(0x06f1, 0xb010),
   .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) {
   .vendor_name = "Opcode",
   .product_name = "MIDIport 32",
   .ifnum = QUIRK_ANY_INTERFACE,
   .type = QUIRK_MIDI_FIXED_ENDPOINT,
   .data = & (const struct snd_usb_midi_endpoint_info) {
      .out_cables = 0x0003,
      .in_cables = 0x0003
      }
   }
},

[steevc]

Just spotted another couple of new USB 2.0 interfaces where the manufacturer claims they work on Linux due to class compliance:

http://wiki.linuxmusicians.com/doku.php ... sound_lyra

It looks like you need to controller app to really use them. Maybe it works on Wine or someone can write one. Judging by their other products I assume these will not be in the budget price range.

It's some sort of step forward if the manufacturers actually acknowledge that Linux support could be a selling feature.

[Thad E Ginathom]

Just glanced over their web page ...

For Lyra, we have created a unit that is compatible with the widest range of computer hardware by using a USB2 interface. This is a UAC2 (USB Audio Class 2) interface supported natively in Mac, Linux and Android, and in Windows via a driver.

... Looks good, if expensive!

EDIT: but no control panel, so I guess that's functionality limited.

[bassomat]

Hi there,
on my seek for a good interface I found this threat. I have a audiointerface, which I think is quit professional and works with debian wheezy really good. The Echo2 by Echoaudio. I must admit that I haven't configured jack so far because it is in first place a audiophile playback interface to my Wall Audio hifi tube amp. But it designed for low latency so I think jack will have a good performance. I will tell you when jack is done. If anyone has a good debian wheezy howto for jack I would really be glad to get that. I play directly trough alsa and uninstalled pulseaudio. Hope that helps in the discussion. I think someone could also try apogee or anything with coreaudio support that should work. Perhaps I could get a apogee duet to test, I know someone who has one. I wouldn't buy from a company which only supports apple.

[j_e_f_f_g]

try apogee or anything with coreaudio support that should work.

The Duet is not functional under Linux. And CoreAudio is MacOS's audio system, which doesn't run under Linux, and isn't compatible with any linux audio API, so doesn't speak to Linux support.

[j_e_f_f_g]

on my seek for a good interface I found this threat.

Given the troublesome state of linux audio support, "threat" is probably the right word. Using audio on linux is like being in Zappa's "Dangerous Kitchen":

In the dangerous kitchen,
If it ain't one thing it's another.
In the middle of the night when you get home,
the bread things are all dry 'n' scratchy.
The meat thing where the cats ate through the paper.
The can things with the sharp little edges
that can cut your fingers when you're not looking.
The soft little things on the floor that you step on.
They can all be DANGEROUS!

Sometimes the milk can hurt you
(if you put it on your cereal
before you smell the plastic container).
And the stuff in the strainer
has a mind of its own.
So be very careful
In the dangerous kitchen,
when the night time has fallen,
and the roaches are crawlin'.
In the kitchen of danger,
you can feel like a stranger.

The bananas are black.
They got flies in the back.
And also the chicken
In the dish with the foil
where the cream is all clabbered.
And the salad is frightful.
Your return in the evening
can be less than delightful.

You must walk very careful.
You must not lean against it.
It can get on your clothing.
It can follow you in
as you walk to the bedroom,
and you take all your clothes off.
While you're sleeping
It crawls off.
It gets in your bed.
It could get on your face then.
It could eat your complexion.
You could die from the danger
of the dangerous kitchen.

Who the fuck wants to clean it?

It's disgusting and dirty.
The sponge on the drainer
Is stinky and squirty.
If you squeeze it when you wipe up,
what you get on your hands then
could unbalance your glands, and
make you blind or whatever.
In the dangerous kitchen
at my house tonight.

[bassomat]

How do you know that the apogee device isn't supported? If you have tested it, ok I don't have the work; or have you heard it or do you think it doesn't work, than you should not write that it doesn't work.
I read somewhere (just seeking where it was) that interfaces that run with the Ipad are supposed to run with the snd_usb_audio module. In the case of the Echo2 I tried and it works. There is no hint at the Echo homepage, but there was a picture of the Echo2 connected to a Ipad, so I bought one and tried. In Germany i could have sent it back, if it hasn't worked. As far as I know the Ipad needs a generic driver, the coreaudiodriver, so maybe coreaudio=Ipad support=snd_usb_audio support=linux support. maybe I'm not right, let's find it out.

[tatch]

Now there is another new Focusrite interface that is much higher quality than the scarlett. It's meant to compete with the Apogee Duet and RME Babyface. It's called the Forte. To be honest, for the price, I think that the RME is a better unit. The Babyface has hardware DSP EQ and compression. But its reverb is software based, although it is very efficiently implemented in RME's much-praised Windows driver. The Forte's DSP are all software. And focusrite's Windows drivers aren't as good as RME's (ie, worse latency and stability). But hey, this is a linux forum, so who cares about that? The Babyface isn't 2.0 compliant, and it isn't supported by ALSA. If the Forte is 2.0 compliant, here's finally a new, quality interface that Linux supports! Is it? Nope. WTF??? Focusrite simultaneously releases 2 new interfaces, and although it's obvious that both could have supported linux, the more pro one doesn't. This company that purportedly is good to linux just gave a big FU to linux users. It said "You linux people are good for only $80 hobbyist stuff. The nice stuff is too good for you". Seriously. That is exactly what their marketing just said to you.

http://focusritedevelopmentteam.wordpre ... -products/

Note that Forte’s display will not function on Linux as its content is rendered by a daemon running on the host. I don’t think this should affect its operation as a sound card though.

is this information wrong?

[bassomat]

You're right, so the thing is, that the mixer or effect are software implemented by Apogee and Focusrite. The Echo2 settings are all hardware implemented.

[Shadow_7]

The basic issue as I see it, is that hardware manufacturers for the most part, do not provide a linux driver for their hardware. A condition that is beginning to shift IMO. Mac OS X, and andriod devices, and ARM things that have reached a level that they could be used as desktop machines. So wanting a cubox or utilite quadcore at the moment.

As far as windows for pro audio, I find that a little hard to swallow, although it probably is true, with caveats. Like that particular machine is running windows that has been optimized for audio, and otherwise left alone of any and all things that a pc might be used for besides audio. And probably not a networked machine either, while doing audio. But I wouldn't know as I haven't run windows much since about 2002. Which was the last time that I had a significant job in I.T. and did development for a primarily windows based company.

There is a sort of silver lining. In that there are very pro-ish stand alone devices that record audio. Many of them can't multi-track, but some can. I have a korg MR-1000 that does 24/196 sampling. But only 2 channels and it doesn't multi-track. The results are just as pro in quality as most other devices. And if you're a one man band, more than sufficient. With a bit of creative editing you can accomplish multi-track style recordings.

The USB 1.x bandwidth is quite limited. Even if you had a device and driver for 24bit 96kHz, you'd be hard pressed to have more than maybe two channels. Maybe even crunched for two channels, which is one in and one out, the minimum needed to multi-track.