interface - USB.3 vs .2 vs PCI bus vs LAN

[Mister Natural]

still not completely happy with the(minute) latency from my Tascam u7k w/usb 2.0
would one of the current usb 3.0 be faster or should I go with a PCI card-device or an ethernet interface ?
peace

[BertKoor]

USB2 technology is in principle not the bottleneck. Theoretical throughput of USB2 is 480 megabits per sec. Assume only half is used and 10 bits needed per byte, that's still 24 megabyte per second. A 24-bit stereo channel at 48kHz needs just 288 kB/s, so there's room for like 80 of such channels.

Several manufacturers such as RME have made USB2 interfaces with very low latency. But that is quite an achievement. Manufacturers that have mastered the art of writing robust lowest-latency drivers can be counted on one hand.

[Mister Natural]

Thx Bert - “on one hand” would be 5 brands available with not good, but great usb drivers
Who are they ?

[BertKoor]

Two I know by heart: RME and ESI. There are a few more... Hopefully others chime in to complete the list.

Avoid like plague: Focusrite. That is, if you are on windows.
These seem to work pretty well on Mac. So they are like the new MOTU on the block.

Hmm, 14 pages of information & opinions on audio interfaces:
viewtopic.php?f=102&t=517198

[Mister Natural]

thx Bert
- very little mention previously here of ethernet-connected interfaces or of modern PCI cards(this coming from a former user of the fabled EMU 1616ucard)

[lunardigs]

RME for sure. I'm using a Fireface UFX in 'class compliant mode' (menu option) via USB2 upon Linux. This means the kernel is the driver, not RME. No problems at all; solid performance. I can do 5ms on smaller projects; play live guitar, vocals, keys, etc.

I've heard too that Focusrite does pretty good on Linux. Although, I don't have any experience with that. Here again it would be the kernel, not an OEM driver.

I've also heard that the Hammerfall PCI cards from RME are about the best one can get for Linux. One day I'll probably go down that route. Yet again though, the Linux kernel would be the driver.

[jancivil]

the drivers on my Presonus Quantum are hyped as “The lowest latency on Earth”.
and apparently is the one interface that takes advantage of Thunderbolt 3. The difference is its Direct Memory Address.

I have a *heavy* template running, keep piling on and my project remains at 8,5 round trip (@ 192 samples buffer). All virtual insts. Normally the system is buckling long before this. never planned to spend $600, but well worth it.

[jancivil]

seems possibly Mac-centric. CF: RME on Mac IME was not what it appears to be under Windows. Def better than onboard, but not what I’d push as very low latency.

but normally USB 2 vs 3 isn’t very meaningful for this kind of application.

[Pictus]

https://www.gearslutz.com/board/showpos ... count=3210

[AdvancedFollower]

In terms of bandwidth, USB 2.0 is already more than fast enough. USB 3 is essentially latency free (it's in the microseconds range). The polling interval of USB 2.0 is 0.125ms, barely noticeable. So in a properly configured system, there's no difference in practice for audio applications.

Latency is primarily a function of the buffer size. This is the smallest "bucket" of audio that can filled, packaged and sent to the audio interface at a time. Any new audio that gets generated (such as when you press a key on your MIDI keyboard) while one bucket is filling up will have to wait for the next one. So the smaller the buckets, the lower the latency. However the system has to be powerful enough to keep filling them up in the allotted time, since buckets of half the size have to be shipped twice as fast. Otherwise the buckets will get yanked before they're filled, resulting in audio crackles and breakups.

For example, at 44.1 KHz (44.1 thousand samples per second), a buffer size of 256 samples is 5.8ms of audio, so this is the smallest possible slice and the lowest theoretical latency. At 88,2 KHz, it's half that, 2.9 ms (since the same number of samples now correspond to half the length of audio).

So to get low latency, you need to simply set the buffer size as low as possible. If your system can't keep up and the audio breaks up, there could be a million reasons for that (DPC latency, bad drivers, devices hogging the USB bus, CPU core parking or power saving etc.). However the only way to even start to reduce the latency is to decrease the buffer size, and then figure out why the system can't keep up.

(Then you have to factor in that many plugins introduce additional latency, and most DAWs compensate this by introducing the same latency to every track to keep things synced).

[Scotty]

In terms of bandwidth, USB 2.0 is already more than fast enough. USB 3 is essentially latency free (it's in the microseconds range). The polling interval of USB 2.0 is 0.125ms, barely noticeable. So in a properly configured system, there's no difference in practice for audio applications.

Nice theory but in practice there is a significant difference between the best USB 2 interfaces in terms of low latency support and PCI(e) based interfaces. For whatever reasons even RME can't do better or even equal their own PCI based interfaces using USB2 or USB 3. That is the way the cookie crumbles.

[jancivil]

It is a little odd to see an argument on latency that set 'drivers' aside as though for later consideration.
Historically the PCI-e was the fastest connection to the CPU etc, probably demonstrated to some extent in tests. I don't know a lot other than that.

Here's the copy on the Presonus Quantum tech:

The Quantum driver utilizes the bus master Direct Memory Access (DMA) to transfer audio data directly to and from the main memory without using CPU processing and the overhead that would come with it. DMA supports 64-bit addressing on systems with 4 GB or more of RAM. A companion DMA engine was also implemented in the Quantum hardware to read digital audio data directly between the ADC/DAC and the computer memory, one sample at a time.

For maximum efficiency, samples are transferred from the Quantum DMA engine directly into driver memory as a 32-bit word to match the way the Quantum driver handles the audio. Where possible, audio samples are also transferred into driver memory in the exact order that the driver expects. This helps to avoid alignment problems and the like, allowing you to run your Quantum drivers at extremely low buffer settings without overtaxing your CPU.

They are boasting of less than 1ms round trip in Studio One, at 64 buffers. I don't know what's in that project, of course.

I have a new computer, and did nothing before this interface arrived. I started with something that always presents a problem for a system, an insane Absynth patch with like 20, 30 s. long envelopes and a lot of action in them, to test the waters. I sez, ok, 192 is a modest start, let's see if I can even manage. Surprisingly, the reported rt latency reads 4.167ms in, 4.333ms out. And, no problem. Now, typically (and this includes every experience with my old RME Fireface card on the PCI-e bus) the next bit is going to involve rendering the Absynth track soon, if not right away, and there is no chance I'm going to do any drumming live because the latency is already far too high. Nope. I kept adding to the arrangement and there is only some audio breakup if I hit playback with things like long cymbals ringing out or like that, an insane thing from my vantage point asking the system to do all of this in real time (let alone asking Cubase to, to boot). I'm still having drum hits (I mean BFD3 with a perfunctory controller) land on the timeline predictably and spot-on.

I think this tech obviates certain bottlenecks in a system. An eye opener a couple yrs back was an article on real time performance versus your specs which you'd think would out overall but do not. This DMA takes the CPU out of the equation partly, so... this is new.

[Mister Natural]

so Jan says dma is a new tech & I'm reading today(naturally) about dante & this also seems like a new tech . . . that I know nothing about. There's no surprise in that but I am fascinated in bettering what I'm using for this digital task
thx Pictus for the graph - it's curious that the speeds rated in this graph are almost exclusively inverse to the street cost of each product
peace

[lunardigs]

DMA is a serious advantage--albeit a security risk. Nonetheless, it's pretty optimal for audio streams.
USB 3.1 supports DMA too. Firewire of course. PCI has it inherently ...

[yellowmix]

@Mister Natural the graph measures performance, not latency time. Greater is better/faster, it's missing the context (you need to go to the DAWbench site for methodology here: http://www.dawbench.com/audio-int-lowlatency.htm). Note RME HDSP is the benchmark everything else is normalized to.

OP's existing interface has some pretty horrendous latency according to Google results (> 18ms RT). The RT latency of the bottom-most entry on the graph is ~10ms. OP's interface wouldn't be on the graph at all. Any interface on the graph would be an improvement.

So the only question is what maximum latency does OP find acceptable.