[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Date Index][Thread Index][Author Index]

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  
>>> reality)
>> 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  
>> time.
> but beware, DAWs won't automatically compensate if you use an  
> external AD converter.
> Mobius does not compensate for every function, no looping software  
> can.

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  
> noticeable.

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

Per Boysen
www.boysen.se (Swedish)
www.looproom.com (international)