] [Thread Prev
Nerdy latency talk (was: Laptops -dedicated to music only?)
>> On 28 jun 2007, at 12.07, andy butler wrote:
>>> afaik best possible for Windows is 3mS from in to out.
>>> (+ AD/DA times)
>>> ( though I don't know if anyone achieves that figure in harsh
>> Generally you should be able to achieve lower buffer settings with
>> good ASIO drivers on a Windows system compared to OS X, if both
>> systems run on equal hardware. That's because OS X keeps some
>> sort of safety margin.
On 28 jun 2007, at 14.05, andy butler wrote:
> thank you,
> any figures to give an accurate idea of the difference.
Sorry, I have no figures. I learned this in discussion with people
that take interest in such technical details because they develop
audio software and since I only have interest in this as a user I
never memorized the exact details. But the figures for buffer
handling should be easy to dig out from the OS X developer
>> The next question would be why you need 6 ms rather than 12 ms? I
>> honestly can't tell.
> I can tell.
What I meant was more like: If 12 ms delay sounds bad it doesn't
sound less bad with 6 ms (hence my question "why prefer 6 over 12") ;-)
>> Finally, all DAWs and the looping software Mobius (Windows XP) do
>> proper compensation for any latency induced by the hardware. Every
>> recording is shifted in time on playback to line up correctly in
> but beware, DAWs won't automatically compensate if you use an
> external AD converter.
> Mobius does not compensate for every function, no looping software
Correct! That's why I find Jeff's concept for Mobius so genius: You
connect right output to left input and push a button, and it measures
the analog output received from an analog input INCLUDING eventual
extra AD converters, or other outboard gera you pass the signal
through before it starts moving air. Then this measured (total)
latency is used for time shifting of recordings.
In the past we had a related problem in Logic because the busses were
not part of the plug-in induced latency compensating system. This
meant that if you set a bunch of audio channels to a bus, as a sub
mix, they would all come out in the mix with the latency of the plug-
ins applied to this particular sub mix bus. If critical for the mix,
you could measure the latency of the plug-ins used on that bus and
slap an extra "time-shift" plug-in on the bus where you keyed in the
negative value to get the timing back on track again. Or you could
simply move the tracks (pre bus/effect etc) manually in time to get
the mix right. Today this is of course history ;-)
> The trouble with latency is that it adds up.
> 2 lots of "negligible latency", added together can
> easy be significant.
> If you're using speakers already, then the pc latency is more
The software should compensate for all software induced latency and
the rest is simple hardware latency, as in AD/DA. Such hardware
induced latency doesn't vary so you should be able to measure it and
rely on the figure.
> 5) Are you already using a guitar>>midi converter, in which case
> you already have
> quite a bit of latency, and any more starts to hurt.
It's natural to adjust your playing according to any given latency.
However this MIDI guitar converter is a typical example of something
you can never learn to compensate for, simply because it is not
consistent (as "distance through air" or "AD/DA conversion") but
varies for different notes.
Greetings from Sweden