Latency: How much does a new computer help?
I made what was arguably a mistake, playing my keyboard into my audio interface, into but unprocessed by a DAW (Ableton Live), out my audio interface again and into my speakers, while simultaneously listening to the signal straight from the piano through headphones. I discovered a noticeable difference in the timing of the two signals. Ever since, I notice latency when I play through the speakers. It’s probably always been a problem, but now I recognize that it’s hurting my timing.
I have for a long time planned to play live using only VST synths (processing the MIDI for sure, and maybe the audio too, with Max). Now I’m wondering whether I have to invest in hardware synths, and forego any live computer-based audio processing.
My computer is an MBP only a couple years old. I’m sure a new one would help, but is there any way to anticipate by how much?
The audio interface is a MOTU UltraLite MK3 Hybrid.
My employer said I could put music software onto the computer they’re letting me use, which is newer but might actually be *worse*: My personal 2.5 year old 15" MBP has these specs:
OS X 10.8.4, 2.2 GHz Intel Core i7, 8 GB 1333 MHz DDR3 RAM
and the 13" MBP they’re letting me use has these ones:
OS X 10.8.5, 2.5 GHz Intel Core i5, 4 GB 1600 MHz DDR3 RAM
If it’s just latency, your computer is probably fine, you just need to adjust your vector sizes. In Max, you go to "Options" > "Audio Status…" and adjust the I/O vector size.
If you’re getting dropouts, that’s another issue, but even then there are still a lot of things you can do before buying a new machine.
Ooh, shrinking that did help! Thanks.
Is latency through one’s computer substantially affected by the amount of processing it does to the signal, or does audio vector size dominate that? (I use some Reaktor VSTs from within Max. Mostly EQ, distortion, gates, none of it involving much explicit, intentional delay.)
Generally speaking, the vector/buffer size does dominate that. Smaller buffer size -> less latency but more CPU intensive. Therefore if you are getting dropouts because you have too much (CPU intense) processing going on you might try increasing the buffer size introducing more latency, "giving you CPU more time to work on a vector".
So, it is interconnected.
"The audio interface is a MOTU UltraLite MK3 Hybrid."
i’ve got the same. changing ‘I/O Vector Size’ as Peter suggested, in "AudioStatus…", is the same as setting the MOTU’s hardware-buffer size.
Whereas setting ‘Signal Vector Size’ in "AudioStatus…" is setting Max’s internal vector processing size.
Smaller ‘I/O Vector’ will shorten delay on live-input, whereas the ‘Signal Vector’ will shorten latency through your Reaktor VST processing chain(mainly in terms of the reaction of those VSTs to parameter changes).
I’m on an old MBP IntelCore2Duo from 2008(3GHz), and i still get good performance leaving both sizes at 64(which is the standard control-rate-locked-to-sample-rate for other environs like PD and SuperCollider).
At 44.1KHz sampling-rate, a vector size of 64 should only give you 1.45ms of latency. Very workable in a live setting.
But you can get away with more:
vs of 128 = 2.9ms latency
vs of 256 = 5.8 <-starts to get annoying right about here :D
but also if you boost up your sampling-rate(albeit CPU will be taxed higher), at 48k, 64vs = 1.333ms latency, etc. or at 96k, 64vs = 0.6666ms… the latency will decrease then as well.
[latency = vector-size/(sampleRate/1000.)]
all depends on what you use your CPU for, and how much latency you're willing to compromise for it as mentioned before, but you can adjust it in different ways…
this is an important doc page about it, too:
buying a new computer would probably speed things up, but a smarter upgrade would be to go by long-term advances in CPU chipset(if i had gone from an IntelCore2Duo 1.5GHz to an IntelCore2Duo 3GHz, the difference would not have been as noticeable as going from an IntelCore2Duo 3GHz to a newer I7 that can clock as high).
better to wait on buying new gear and try to utilize what you have as best as possible first.