Audio Interfaces Under Linux
@ccaudle
Take with a grain of salt until proof is shown, however when Dante first started picking up, one of the selling points WAS interoperability with AVB...
http://www.lectrosonics.com/europe/images/PDFs/audinate%20avb%20white%20paper%20v1%202.pdf
While Lectrosonics is hosting it, the document appears to be written by Audinate based on the branding on it, and matches my memory as well.
I am not really diving into technical details here, just giving broad strokes. Yes you are correct in that there is a revision of AVB that runs on IP, I have no idea who is using it or not, because frankly I rarely run into AVB at all at this point, as I said Dante has the crown for the time being in the live sound world.
In as far as Ravenna on Linux, can't find any reference to it at the moment, thought I had heard about work actually looking hopeful in that direction at one point but can't find it now, other than conversations like this...
https://groups.google.com/forum/#!topic/crc-mmbtools/uQ9s70yNr58
Which suggest it may not be all that difficult to get them running, and AES67 being a more open standard from what I have been told, it could work towards that favor. I do not know of anyone working towards that currently. Funnily enough there was some work by Intel on AVB on Linux IIRC though.
Seablade
I would say lets take the Audio over IP conversations to the other thread...
https://community.ardour.org/node/13556
Confusing having it in two places.
Seablade
@soundpro69,
I have M-Audio Fast Track Ultra 8R with 8 mic inputs. It works without problems with Ardour (in GNU/Linux).
More details in this article:
http://heikki.ketoharju.info/2013/03/linux-and-fasttrackultra/
I also have E-Mu 0404USB which works perfectly with Ardour if using 44.1kHz or 48kHz sampling rates.
I have been using Ardour for seven years. I'm a big fan and I want to thank Paul and all developers for great work.
I've heard the Behringer Xenyx Q802USB works with Linux but my question is can I record two tracks (guitar and vocals) at the same time? or does anyone know of a low cost/portable interface that will let me record with at least two tracks at a time. I have a small home PC studio but I needed a light portable studio as I've been traveling a lot lately and Ubuntu works great on my old laptop.
any suggestions are welcome
@waderain the Xenyx series only lets you record the stereo mixdown, not the individual channels, so you could pan your two tracks hard left and right and then split the stereo channels to mono, but I haven't tried anything like that with my FX1204USB so I'm not sure if that would give 100% separation on each channel. There's the Behringer Uphoria UMC404HD that allows 4x4 on the cheap ($100) but I don't know how the quality is.
@seablade I have to disagree with you about Behringer. IMO they make some great stuff for the money. I have the 12 channel Xenyx and it sounds great, and hasn't given me any problems. Admittedly it only gives stereo input to the pc, but my space prevents me from tracking more than one person at a time anyway.
@braxtons12
I've looked into the Behringer UMC204HD, which is very similar to the 404. I read mixed things about that some say it has a background crackle and others say it doesn't. I can't get any info if the 204 works with Linux or not, I assume so but I don't want to assume and plunk down money on something that's not going to work. The two biggest things I need is at least one phantom power and being able to record two tracks, either vocal and guitar or two guitars or two vocals. I have some Behringer stuff and never had any problems with them so I'm not worried about the quality. Just if there are any other alternatives.
@braxtons12
I would suggest you work with them more then. General rule of thumb is if you have to depend on behringer, always carry two for when it breaks.
As I mentioned above, the x32 seems to be a standout possibly due to the purchase of Midas and their expertise, but most of the rest of their equipment ranges from poor dependability, to poor quality, to outright stealing of other people's ideas combined with the former two.
To give one example of many I could give, I purchased 20 channels of behringer compression at one point as I didn't have any other choice. Within 7 or 8 theater shows of 2 week runs and one week of tech, over half of them were dead. This is an exceedingly poor dependability record.
Seablade
"General rule of thumb is if you have to depend on behringer, always carry two for when it breaks."
Yep. A lot of the Behringer gear sounds pretty good for the price and is ok for light home studio use, but using it in a pro live sound situation is inviting failures. I have some of their stuff but I'm under no illusions about how long it would last in a commercial venue or touring PA. It does have the advantage of being cheap to replace if it gets filled with beer :-)
only Behringer thing I would stand by on dependability is the BCR-2000.. MIDI controller . Possibly the BCF-2000 as well (mine never died, but I'm not so sure how good those faders were)
I bought a very old (serial number is in 100's) BCR 2000, with a broken encoder and 2 of the LED rings not working (no big deal for me)...
Pulled it apart with a mate to replace the broken encoder.. Wow, that thing has supports and reinforcement coming out of every point and so many screws.
These have a reputation of being able to throw in the back of a van and take to bush doof, and they won't break.. (unless you happen to snap the encoder)... I can see why...
On the compressor front.. Yeah, I had 1 channel die in a quad compressor after a couple of years of light studio use.
I don't think they are all bad, I think they have bad batches..
On the compressor front.. Yeah, I had 1 channel die in a quad compressor after a couple of years of light studio use.
I don't think they are all bad, I think they have bad batches..
@allank
My example was just one out of many over the years I can give:) Bad batches doesn't cover it really.
Seablade
I often see affordable audio interfaces with many inputs and outputs -- one product from (name redacted) boasts 18 inputs -- then come away disappointed when I note that eight of those are ADAT Optical.
I cant speak for myself, but what are the chances that someone building out their first or second personal recording space is going to have an ADAT *anything* at their disposal? IMO, it really is something of a useless feature for anyone seeking a nice multi-input/output standalone audio interface.
Actually, there's a solid argument to the contrary.
Splitting up your gear enhances long term viability and expandability. Putting D/A-A/D into a separate box and running ADAT between it and the computer interface is a smart way to ensure that a failure on one circuit board/box doesn't kill your entire signal processing chain, and allows you to upgrade both the channel count and quality of the converters in the future if you decided to.
Much better idea to buy separate converters and run them to a cheaper interface as your initial purchase.
"what are the chances that someone building out their first or second personal recording space is going to have an ADAT *anything* at their disposal?"
I'd say quite high. You can pick up a used RME HDSP9652 PCI card for 200.00 USD/Euro these days on ebay (you need a PCI slot of course) and if money is tight use something like the Behringer ADA8200 8-channel preamp/converters until you can afford something better.
Well, I got a minidsp USB-Streamer B (https://www.minidsp.com/products/usb-audio-interface/usbstreamer-box - a neat little thing, just USB, ADAT in and ADAT out) and a Behringer ADA8200 hooked up to a laptop as an 8 channel mobile recording system at a pretty good price.
But I also have in the studio an RME Multiface II with 8 Analog inputs and another 8 channels of input via ADAT, and I can use the same Behringer ADA8200 for channels 9-16 on the rare occasions when I need more than 8.
I just got the U-Phoria UMC1820 - works out of the box with Ardour, I'm ALSA only on my install, so I can't comment on JACK, I also have not done extensive testing, and I would not feel comfortable commenting on quality - although it sounds great to me. What I can say is, sound goes in and out, and I got it for a ridiculous price. No SPDIF tests and I haven't got any ADAT gear here. No affiliation with Behringer.
Hi 8p8c
Behringer writes " ... up to 96 kHz" some places, other places they write "... 96 kHz " without reservations. What is your experience? If you can run at 96 kHz without xruns that certainly initiates some deliberations ...
I just had a quick test, mono input (bass guitar, no DI, PAD on, ALSA, no JACK) I tried 64 and 128 samples I managed to generate xruns and a couple of crashes on 96 kHz, tried 256 samples at 2.7ms on 96 kHz and all seems well. No xruns, seems solid, so how well it would cope with multiple audio streams in a full session...? I think it's comparable to my 1010LT, which is damn good, next I'll try MIDI.
This is on a Dell T5400, 8 cores at 3.0GHz, 8Gb RAM 128GB SSD stripped down XFCE installation.
TASCAM US-800 (8-input) works.
At least for audio. MIDI does not work. Don't know why; Linux sees it as a device but doesn't receive MIDI signals.
(I am in fact the person who figured out how to make it work, when that was difficult. But the last few years of kernel builds no longer panic at its misenumerating, so as long as you plug it in after the machine has booted you're good. And they're dirt cheap on eBay.)
I hooked up an ADA8200 to the UMC1820, and - no input, checked alsamixer, only one fader visible. Hmmm. Rechecked the clock setting on the back - all good, two TOSLINK cables, hooked up to a Mac, and the faders were down on the interface, ran Ardour - no problema. Back under XFCE on Linux, tried sudo apt-get install xfce4-mixer, yep - faders show up but are not persistent. Ok, tried Qastools, all components installed via Synaptic, and - yes - the mixer settings are there and persistent. So if this happens to you - install Qastools components and check the faders there.
USB chipsets may matter.
I'm going to drop in here that USB chipsets used in the host appear to matter, possibly a lot, even (particularly?) in the USB 2.0 world. This may explain a lot of performance various people have seen in USB audio devices.
I did a bunch of research late last week into USB host behaviours and found that there are two underlying architectures, one of which (UHCI) uses the CPU to drive most of the work of running the bus (independent of things like transfer speeds) and one of which (OHCI) puts most of that work onto dedicated hardware in the card.
The result is that UHCI hosts (cards) put a lot more interrupts on the system bus, which for our purposes, is very bad. They also consume more CPU, though that's not as big a factor I don't think. Mostly, as linuxmusician tuning pages will tell you, you want to keep as many interrupts off your system bus as you can.
(There's also a matter internally of synchronous NAK vs. asynchronous NAKs, and OHCI wins there too. The tldr if I understand it right is that OHCI can respond more quickly to packet failures; UHCI has to wait until the start of the next frame. Also, OCHI can queue multiple packets (n<4 I think? unclear) at a time, UHCI can queue only one at a time. But I am not that kind of hardware hacker and was gleaning what I could from the Linux USB driver mailing list and developer FAQ.)
I just moved from a UHCI Intel USB host card to an OHCI NEC USB chipset host card, system otherwise unchanged, and my minimum usable buffer setting dropped from 256 samples to 32 (3 frames in each case because USB), with buffer latency dropping from 30ms to 0.7ms, and actual measured round-trip Ardour latency dropping by an order of magnitude. On the UHCI cards (Intel chipset, VIA chipset, tried both) a setting of 128 samples would fail even just at playback, every time; on the OHCI card (NEC chipset), at a 32 sample buffer, I have now made a small number of successful test recordings against multitrack existing recordings, two channel input, without any XRUNs.
This is a big deal if you are running on USB 2.0 or 1.1, particularly on kit like the Presonus 1818vsl, where you don't have access to hardware monitoring on Linux.
I talk about this more extensively here:
http://crimeandtheforcesofevil.com/blog/2016/07/25/so-hey-usb-chipsets-totally-matter/
And before that, discuss OHCI and UHCI here:
http://crimeandtheforcesofevil.com/blog/2016/07/24/usb-2-0-chipsets-digital-audio-workstations-and-linux/
(In USB 3.0, of course, chipsets on both ends matter, because the big deal with 3.0 isn't so much the raw speed, though that's nice; it's that 3.0 is introducing FireWire-like data streaming. Before now, all USB data has been packeted; 3.0 provides a whole new transfer mode, apparently.)
Those latency figures are impressive for a USB connection, but I'm puzzled. A quick search seems to show that OHCI is for USB low and full speed only (12Mbit*), also that EHCI is better than either of the others for higher speeds.
* so "full speed" wouldn't get you more than 8 channels at 24/48.
Yes, EHCI is the top layer for USB 2.0, and needed for USB 2.0 functionality. But EHCI loads and uses the 1.1 drivers underneath it. On linux, you can see this if you cat /proc/interrupts.
And regardless, if the card has protocol support in the hardware (required for OHCI), EHCI is going to use that hardware support, either directly or indirectly. And if the card doesn't have protocol support in the hardware (not required - or present - in UHCI cards), it's going to hand those duties to the CPU, and generate more interrupts.
Either way, you are going to get the same result, even with EHCI. The hardware is either present in the card, or isn't. OHCI cards have the protocol handling in the hardware, UHCI cards don't. If it's not there, you have more interrupts and more processor handling of Stuff, even in EHCI.
All of my posted new results are EHCI running atop OHCI, vs the old results which were EHCI running atop UHCI.
@solarbird: May I ask which card did you purchase specifically?
FYI - Last night I set up my Steinberg UR22 (MK II) with Ardour. I am running Ardour in Linux Mint 17.3. In my audio set-up I set up UR22 as my input and output. I just plugged the interface in and it was recognised. I recorded guitar and it worked a treat. However, as yet I have been unable to get it to work when I use Ardour in Elementary. I am running Linux on a late 2011 macbook pro.
dsreyes1014: Syba SD-PEX20019 PCI Express USB 2.0 interface card. Mostly because the documentation specifically mentions that it uses standard OHCI drivers with no additional software needed, and on some digging, I found out it uses a NEC chipset.
Also it would be neat to see if this kind of improved performance shows up for other people as well, so post your results if you decide to try it.
I was pleasantly surprised to find my Zoom R24 actually works, both as an interface and a MCP surface. I'm still tweaking my latency and MCP profiles to do useful stuff with the buttons, but it seems to work.
solarbird: I bought the PEX 250019 card and did some tests. I was not quite able to replicate your findings, but it may be because differences in our hardware. My only desktop computer with PCIe slots is a old high end pc and because of this the chipset and it's USB might be better than in cheaper pcs. I found the motherboard USB latency performance be nearly (but not quite) as good as the PEX250019 USB card. If your motherboard USB is crappy, then the PEX 250019 might be a good choise.
Hardware and software:
----------------------------------------------------------------------------------
- HP xw8600 Workstation
- Bios Version: 1.32
- 2x Intel 4 Core Xeon X5450 3.00GHz processors, totaling in 8 cores.
- 12 GB Ram
- CPU Frequency Governor = Performance
- Nvidia Geforce GTX 960, driver: Nvidia 361.42
- Display 1920 x 1080 HDTV HDMI
- Motherboard USB: Intel 631xESB/632xESB/3100 Chipset EHCI USB2 Controller
- USB Add-on Card: PEX 250019 OHCI Usb Card with Nec chipset
- Ardour 5.4
- Kubuntu 16.04 + KXStudio repos
- Sessions saved to an internal Sata SSD disk (mount options: noatime, nodiratime)
- Recording 10 minutes of 8 channels, 48 kHz, 16 bit, wav (4 GB limit), Recording starts automatically using Punch In and Out. Jack / Alsa Buffers set to 2.
- Alsa 1.0.25
- Jack 2.1.9.11-20160620-5
- The latencies below are reported by Cadence and Ardour. These numbers are about half of what QjackCTRL reports with the same Jack settings.
lspci -v
----------------------------------------------------------------------------------
00:1d.0 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #1 (rev 09) (prog-if 00 [UHCI])
Subsystem: Hewlett-Packard Company 631xESB/632xESB/3100 Chipset UHCI USB Controller
Flags: bus master, medium devsel, latency 0, IRQ 16
I/O ports at 2000 [size=32]
Kernel driver in use: uhci_hcd
00:1d.1 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #2 (rev 09) (prog-if 00 [UHCI])
Subsystem: Hewlett-Packard Company 631xESB/632xESB/3100 Chipset UHCI USB Controller
Flags: bus master, medium devsel, latency 0, IRQ 19
I/O ports at 2020 [size=32]
Kernel driver in use: uhci_hcd
00:1d.2 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #3 (rev 09) (prog-if 00 [UHCI])
Subsystem: Hewlett-Packard Company 631xESB/632xESB/3100 Chipset UHCI USB Controller
Flags: bus master, medium devsel, latency 0, IRQ 18
I/O ports at 2040 [size=32]
Kernel driver in use: uhci_hcd
00:1d.3 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #4 (rev 09) (prog-if 00 [UHCI])
Subsystem: Hewlett-Packard Company 631xESB/632xESB/3100 Chipset UHCI USB Controller
Flags: bus master, medium devsel, latency 0, IRQ 22
I/O ports at 2060 [size=32]
Kernel driver in use: uhci_hcd
00:1d.7 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset EHCI USB2 Controller (rev 09) (prog-if 20 [EHCI])
Subsystem: Hewlett-Packard Company 631xESB/632xESB/3100 Chipset EHCI USB2 Controller
Flags: bus master, medium devsel, latency 0, IRQ 16
Memory at d3404000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Capabilities: [58] Debug port: BAR=1 offset=00a0
Kernel driver in use: ehci-pci
a1:00.0 USB controller: NEC Corporation OHCI USB Controller (rev 43) (prog-if 10 [OHCI])
Subsystem: NEC Corporation USB Controller
Flags: bus master, medium devsel, latency 32, IRQ 24
Memory at d3500000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2
Kernel driver in use: ohci-pci
a1:00.1 USB controller: NEC Corporation OHCI USB Controller (rev 43) (prog-if 10 [OHCI])
Subsystem: NEC Corporation USB Controller
Flags: bus master, medium devsel, latency 32, IRQ 32
Memory at d3501000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2
Kernel driver in use: ohci-pci
a1:00.2 USB controller: NEC Corporation uPD72010x USB 2.0 Controller (rev 04) (prog-if 20 [EHCI])
Subsystem: NEC Corporation uPD72010x USB 2.0 Controller
Flags: bus master, medium devsel, latency 32, IRQ 31
Memory at d3502000 (32-bit, non-prefetchable) [size=256]
Capabilities: [40] Power Management version 2
Kernel driver in use: ehci-pci
Presonus 1818VSL Sound Card:
Test 1: Jack, PEX 250019 OHCI Usb Card:
----------------------------------------------------------------------------------
- Buffer 128, Block Latency 2.7. DSP = 5.0 - 5.7 %. Xruns: 0
- Buffer 64, Block Latency 1.3. DSP = 9.8 - 10.4 %. Xruns: 0
- Buffer 32, Block Latency 0.7. DSP = 19.8 - 21 %. Xruns: 66
Test 2: Jack , Intel 631xESB/632xESB/3100 Chipset EHCI USB2 Controller:
----------------------------------------------------------------------------------
- Buffer 128, Block Latency 2.7. DSP = 4.9 - 5.7 %. Xruns: 0
- Buffer 64, Block Latency 1.3. DSP = 9.0 - 10.7 %. Xruns: 0
- Buffer 32, Block Latency 0.7. DSP = 16.9 - 19.1 %. Xruns: 37
Test 3: Alsa, PEX 250019 OHCI Usb Card:
----------------------------------------------------------------------------------
- Buffer 128, Block Latency 2.7. DSP = 8.1 - 14.1 %. Xruns: 0, Ardour froze and crashed after 7 minutes of recording. After a reboot on second try Ardour crashed after about 50 seconds of recording when KDE popped up a notification window. The Ardour error message was: The audio backend was shut down because: Alsa I/O Error.
- I did not test with lower buffers sizes because the first test did not succeed.
Test 4: Alsa , Intel 631xESB/632xESB/3100 Chipset EHCI USB2 Controller:
----------------------------------------------------------------------------------
- Buffer 128, Block Latency 2.7. DSP = 9.6 - 13.8 %. Xruns: 1
- Buffer 64, Block Latency 1.3. DSP = 12.7 - 20.7 %. Xruns: 4
- Buffer 32, Block Latency 0.7. DSP = 20.7 - 74.2 %. Xruns: 17, Alsa crashed after 5 min recording with Ardour message: The audio backend was shut down because: Alsa I/O Error.
I then repeated the tests with only Jack and two more sound cards: Behringer UMC1820 and Alesis IO4. The IO4 has only 4 input channels so I duplicated these to Ardour tracks 1 - 4 and 5 - 8 to get the same amount of disk traffic as with the 8 channel cards.
Behringer UMC1820 Sound Card:
Test 5: Jack, PEX 250019 OHCI Usb Card
----------------------------------------------------------------------------------
- Buffer 128, Block Latency 2.7. DSP = 4.8 - 5.9 %. Xruns: 0
- Buffer 64, Block Latency 1.3. DSP = 9.0 - 10.7 %. Xruns: 0
- Buffer 32, Block Latency 0.7. DSP = 16.8 - 18.5 %. Xruns: 3
Test 6: Jack , Intel 631xESB/632xESB/3100 Chipset EHCI USB2 Controller
----------------------------------------------------------------------------------
- Buffer 128, Block Latency 2.7. DSP = 5.0 - 5.5 %. Xruns: 0
- Buffer 64, Block Latency 1.3. DSP = 9.0 - 10.1 %. Xruns: 11
Alesis IO4 Sound Card:
Test 7: Jack, PEX 250019 OHCI Usb Card
----------------------------------------------------------------------------------
- Buffer 128, Block Latency 2.7. DSP = 4.9 - 5.4 %. Xruns: 0. These are the results of the second run, the first run resulted in Ardour crashing just when 10 minutes of recording time was reached.
- Buffer 64, Block Latency 1.3. DSP = 8.1 - 9.9 %. Xruns: 1. These are the results of the second run, the first run resulted in Ardour crashing in 7 minutes.
- Buffer 32, Block Latency 0.7. Jack fails to start.
Test 8: Jack , Intel 631xESB/632xESB/3100 Chipset EHCI USB2 Controller
----------------------------------------------------------------------------------
- Buffer 128, Block Latency 2.7. DSP = 4.3 - 4.9 %. Xruns: 0
- Buffer 64, Block Latency 1.3. Constant flow of about 30 Xruns per second.
I was surprised to see that on this system the Alsa backend did not perform well and was quite crashy.
The other result is that the cheap UMC1820 performed quite similarily than the (at the time of buying) quite expensive Presonus 1818VSL. However the price of the card seemed to correlate directly to latency performance. The cheapest was the worst (IO4) and the most expensive one was the best (Presonus 1818VSL).
I was also surprised to see Ardour crashing, there is something in this system that makes Ardour more unstable compared to my laptop Gentoo system. On the Gentoo system Ardour almost never crashes anymore. It can also be caused by the combination of: sound card chipset, USB controller chipset, Alsa version, OS and kernel configuration.
I did not try to repeat the tests, so these results are not very reliable. I should have repeated each test say 5 times, but it would have taken too many hours to do so. In my experience there is also some randomness in Xrun occurences, often many happen in a short period of time and then there is no Xruns for many minutes. There is no way of sorting out the randomness now because I did not repeat the tests.
I'm not a fan of trying to run the system on as low latency as it goes, because it makes recording / playback unreliable. You get the best performing and most reliable system by bying a card that has analog zero latency monitoring and using big buffer sizes. In this way you get rid of all latency and also get the most stable system.
The only use case for low latency in my opinion is playing soft synths with a midi keyboard. Then there is no way getting around the inherent latency of computer audio.
@seablade:
I had not heard of anyone working on Ravenna or AES67 support on Linux, do you have any references to that work?
Re: AVB that runs on layer 2 (raw Ethernet) not on top of the IP stack like AES67, so they are not compatible. The AVB spec has provision for transport over IP, but I don't think anyone is using it yet, all the designs I have looked into run directly on the Ethernet layer. The clocking is also using IEEE1588 directly on the Ethernet layer, and AES67 uses IEEE1588 over IP, so there are enough differences you could bridge between them, but it would be difficult for direct interoperability.