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

Re: [Fwd: My new music laptop: Dell Studio 1747]



andy butler schrieb:
>
>> with a buffer size of 128 (which corresponds to roughly 3ms latency). A 
>
> that's rather optimistic (well, I guess you know that really, but
> it's perhaps misleading)
>
> 128 samples @ 44.1kHz indeed corresponds to 3mS.
> ...but that's only part of the story.
>
> Total latency is
> A/D conversion + Input Buffer + Output Buffer + D/A conversion.
Quoting from an article I wrote some time ago (but which has become 
unavailable when I moved my website...at least for the time being):
"[...], we will further split up the latencies found here:

a) the signal is converted by the A/D converters of the audio interface

b) the signal is buffered by the audio interface's input drivers

c) the signal is processed by the audio application (e.g. an amp simulator)

d) the signal is buffered by the audio interface's output drivers

e) the signal is converted by the D/A converters of the audio interface

Ok, so we normally get a specification by the interface manufacturer 
which says something like "latency down to 4ms with zero-latency 
monitoring". So what does that mean -- does that mean that C2 is 4ms and 
if we only monitor the signal (i.e. leave out the b-d steps) we get zero 
latency? Certainly not. The latency specified by the interface 
documentation is only b) and d).

So first, what about those converter influences, a) and e)? You normally 
have a hard time finding out those, even when looking at the data sheets 
of some really high-class stuff (think Apogee). You might find them if 
you know the converters which are used and then looking up their specs. 
What comes out here is something like this: you have several latching 
delays etc. which are in the ns range (and will not be considered 
further). Then you get a delay of the digital filter, which is usually 
specified as a multiple of the inverse sampling clock and comes out in 
the 0.1ms range (this for 44.1/48kHz sampling rates, less for higher 
ones). You may or may not have a specification of a pipeline delay, 
again in the 0.1ms range. But even when summing all those effects, we 
get something around 0.2-0.3ms in each direction, or half a ms in both 
ways -- so we won't consider it any further."

So I came out with 0.2-0.3ms for the converters, and then @44.1kHz 
128/44.1E3=2.9ms -> in total about 3.2ms. And obviously, if you're going 
in and out, that's 6.4ms.

What's more interesting is that your application and any plugins you may 
be running in-line ("c" above) add to that latency.

Rainer

ps: If you think the description above is incorrect, please let me know.

And pps: This (128ms setting) works only if I do like you also pointed 
out recently and remove the audio app from the core the audio interface 
driver uses. Btw, there's a new interface driver out now which 
supposedly performs way better on Windows7. Perhaps I can get even 
better than the 128ms (which I easily can accomplish on my 
Kentsfield-equipped computer using RME HDSP interfaces).

-- 
http://moinlabs.de
Follow me on twitter: http://twitter.com/moinlabs