Latency and audio interfaces
Hello everyone,
I don't understand how much my audio interface has to do with latency issues. I get that there is a basic level of latency associated with any particular card, but it's really the buffer size that determines the significant portion of your latency these days, and that buffer size is solely a CPU-side thing, no?
My situation is: I'm using the USB audio send/return on my Zed14 mixer as a temporary replacement right now, and I'm having to keep the audio buffer at 256 samples with all my processing running to avoid clicks. I have my eye on a Focusrite Saffire 24 DSP, and I would love to get my latency down lower, but if I'm right about buffer issues being on the CPU side, then it's really a faster computer that I need, moreso than a newer audio interface. Is that right? Also, if I'm running 2 in/2 out now, and would like to go to 4 in/ 4 out, how can I expect that to alter my required buffer size? I mean, that increase is obviously putting more load on my CPU, but is it significant?
Cheers.
(I have tried finding answers to this online but haven't had much luck.)
There are a few sources of latency that all add up to create the total
latency. Buffer size, transport protocol, mixing, are all factors.
Most pro audio interfaces have hardware mixing. A cheaper interface will
rely on the OS to do audio mixing in software. This adds some delay in
getting the data to the audio hardware.
Also, USB devices tend to be more latency sensitive because the USB protocol requires that the host manage the protocol traffic. Firewire
offloads that to other devices on the serial bus.
I don't think a faster processor will make things better because
the bottle neck is not the CPU it is data through put.
I agree with Anthony, nowadays the cpu is rarely the bottleneck - but it is also true that the less strain you put on your cpu, the less latency you may hope to achieve.
256 samples @ 44100 Hz is not a bad latency value anyway... I doubt you can push it much lower, whatever the interface. I don't usually get lower than that with my motu traveler. (yes, I can try 192, but it's quite risky)
On the other hand, I doubt you can use 4/4 with an USB interface - regardless of latency... unless you're talking about USB2, which is better (though not ideal anyway...)
As far as I know RME cards give the best latency values - and an amazing overall quality, but again don't expect much less than 256 under normal conditions...
anyway, did you try to change your Signal Vector Size in Max's DSP status window? it might help you (or might not... you have to try...)
Cheers
aa
I generally run everything at 128 samples buffer at performances - and no problems - and I am doing some pretty complex stuff live. This is with a macbook pro dual 2.4GHz and a MOTU Ultralite (Firewire). If I am doing really simple stuff I can go to 64 samples.
The audio interface can make a difference as far as CPU usage - my presonus firebox for some reason gives CPU spikes every few seconds whenever it is plugged in. This caused me (in my single-processor G4 days) to be able to use less DSP to not get pops than I could with, for instance, the built-in audio. When I got the MOTU, even with the same 1.25GHz G4, I could do more. Don't know why - but the presonus was using apple's class-compliant firewire audio interface driver - maybe that is just not very good. But that difference in CPU usage of the interfaces is small now compared to the power of current processors.
As for more channels, I don't notice that my ultralite takes any more CPU than things with only 2 in/2 out. Matter of fact, I have witnessed a macbook pro taking in over 75 audio input channels via a custom ethernet interface (David Wessel's pads) and not sweat at all. Now recording all those to disk would be different, but the throughput is there.
Are you sure the bottleneck is the data put through the CPU, not the CPU itself? I might dispute that - I can send hundreds of channels around in Max/MSP just fine, but if I try to run 10 or 12 FFTs at once instead, that starts giving me pops and clicks - less data, but more processing needed to be done on it per unit time. Just my take - feel free to prove me wrong.
cheers,
Arvid