Subject: RE: [linux-audio-dev] Random thought on HDR latency compensation
From: Richard W.E. Furse (richard_AT_muse.demon.co.uk)
Date: Sat Apr 22 2000 - 12:40:57 EEST
Now here's a fun subject!
This problem is actually quite common - MN has a small subsystem to deal
with it and the paper I'm try to write has a few sections on it. I quote
(the current sketchy form of) the introduction:
"The term 'latency' is used to describe a number of senses in which a
digital signal can be late. We separate some of these using the following
terminology:
"1) 'Frame Latency' is an upper bound on the delay caused because a
complete frame of audio needs to be constructed before the first sample can
be output. This is given by frame size minus one.
"2) 'Process Latency' is the actual time it takes for the unit generator
(or overall architecture) to perform a frame of processing. The host can
extract this from the unit generator by timing its operation under varying
circumstances although statistical techniques may be needed.
"3) 'Systematic Latency' is the latency implicit in the processing because
the unit generator essentially needs to 'look ahead' before it can produce
its output. Examples of this include non-causal filters, for instance
non-causal compressor algorithms. Another is a unit generator that receives
an audio stream and sends an event stream of windowed Fast Fourier
Transforms every 1024 samples. As the frame boundaries may not coincide
with the 1024 sample blocks required actually to perform the FFT the unit
generator cannot output the event until the block is complete. The unit
generator has a precise gauge of its own input and output systematic
latency and can provide these figures to the host.
"4) 'Jitter' is the timing inaccuracy (positive and negative) that arise
when unpredictable events arrive and have to have timestamps changed to fit
frame boundaries. Generally this is limited by the frame size, or half the
frame size when an algorithm choosing the nearest frame boundary is used."
I'm very interested in any changes/extensions to these ideas or alternative
terminology dealing with these issues. As I understand it, Tom Pincince is
describing what I call systematic latency.
When I finally got around to looking at the VST SDK I noticed that VST
plugins publish input/output latency (for "ASIO" apparently). MN unit
generators publish systematic latency (using the terminology above) - does
anyone know if these are the same thing?
-- Richard
-----Original Message-----
From: Paul Barton-Davis [SMTP:pbd_AT_Op.Net]
Sent: Saturday, April 22, 2000 4:22 AM
To: Tom Pincince
Cc: linux-audio-dev_AT_ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Random thought on HDR latency compensation
[...]
>3) Latency in a real-time stream
>
>I have a Sony R7 digital reverb. This device gives me the option of
>using a noise gate before the reverb. The noise gate has a pre-delay of
>zero to a few hundred samples. The gate monitors the signal before the
>pre-delay, and opens when the signal goes above the programmed
>threshold. The gate takes time to go from fully closed to fully open.
>The pre-delay allows the signal to arrive at the gate the instant that
>the gate is fully open. In this way none of the signal is lost. The
>latency of this effect is equal to the number of pre-delay samples
>multiplied by the sampling frequency, since the input signal is live and
>there is no playback buffer. There is no way to improve latency and
>there is no risk of drop-outs. I think this is the kind of latency that
>Jarno and Jorn are referring to.
I understand. I will have to think about this. I have a hard time
accepting this as "latency". Its a device with a delay line. But I'll
reflect upon it.
[...]
This archive was generated by hypermail 2b28 : Sat Apr 22 2000 - 13:12:19 EEST