Subject: Re: [linux-audio-dev] Random thought on HDR latency compensation
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Sat Apr 22 2000 - 06:22:03 EEST
>1) Latency in the recording/monitoring path
>
>If the performer is monitoring himself post a/d during recording,
Presumably, you mean post a/d/a, right ?
>absolute maximum acceptable latency. If the performer is singing or
>playing an instrument with audible acoustic output, delays of 2-20msec
>can produce audible phase interference. If this upsets him, 1msec is
>the maximum acceptable latency.
Tell that to Mackie. The Digital 8 Bus introduces a minimum of 1.3msec
of latency, just measuring the simple A-D-A path through the
mixer. Also, 3msec corresponds to a reasonable distance from a
monitor; if the musician is wearing sealed headphones, then the phase
effects don't matter too much. So I think we can be a little sloppier
on the absolute lower limit.
>2) Latency in the playback path
>So how much latency is acceptable in the playback path? In recording,
>playback latency is only an issue during overdubs. The performer will
>not play anything until he hears a track being played back so, if the
>recording software is capable of offsetting the record start time to
>account for playback buffer size, then the issue here is “how long can
>you keep a musician waiting?” I have found five seconds to be about the
>maximum time before the musician starts loosing his feel for the music
>and starts displaying visible signs of frustration.
I don't understand this model at all. The playback/record offset time
is a constant value, not a variable one. You will start hearing
playback as soon as the data makes it way through the audio h/w
buffers and out to a d/a unit. The sound will then play continuously.
If you punch in during playback and monitor from the HDR system, you
will necessarily have a problem at the beginning and end of the
punch because of this offset - while you monitor the "recorded" signal,
you are listening to data that is "older" than the "playback" signal.
> Five seconds of
>playback buffer can make up for very slow hardware and/or a lot of
>demanding plugins.
If you attempt to use a 5 second buffer for this, then punch-in and
punch-out will sound pretty terrible. In addition, user-space
buffering that exceeds the hardware buffer size on the audio h/w will
make life much more complex for the programmer. Not necessarily a
terrible thing, but ...
> The other issue here is the responsiveness of the
>plug-in to real time parameter adjustments, and is very important during
>mixdown. In this case the recording engineer is like a musician and the
>recording console is his instrument, so we are back to a 20msec maximum
>latency.
From personal experience, I would have said that 5msec is more like
the limit for this. Given that a MIDI Note On takes 1msec, and some
people complain about note smearing on chords, I think that 20msec
would be way to long for this.
>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.
>4) Latency with buffers
>Paul says that plugins have no effect on latency. True, however
>latency, as a function of buffer size, does have an effect on plugins.
>Bigger buffers allow more plugins on slower hardware with greater
>latency and no risk of drop-outs. Smaller buffers offer smooth
>real-time responsiveness but require fast hardware and conservative use
>of plugins or risk drop-outs.
This is true, but only to a point when it comes to the demands of
plugins. Although there is definitely an "efficiency of scale" that
comes from running a plugin chain with a large blocksize (e.g. giving
the chain 64K of samples to process instead of 16 samples), the
benefit is decidely non-linear. In part because of data cache effects,
there is a point at which increasing the blocksize will not help very
much anymore. I don't know what that size is, but I would guess that
its not that large. Its true that you can win on the instruction cache
by staying within the inner loop of a plugin, but I don't know the
magnitude of this effect.
>Soooo, now I can clarify my original comment regarding plugins and
>latency.
>
>1) Can a host application be designed to determine the computational
>ability of the hardware upon which it resides?
>2) Can a plugin architecture be designed that can communicate its
>computational requirements to the host application?
>3) If the answers to 1 and 2 are yes, is it possible/desirable for the
>host application to dynamically resize playback buffers to guarantee no
>drop-outs regardless of hardware capability or plugin load, while
>simultaneously offsetting the start time of recording tracks to preserve
>sample accurate overdubs? This would let the user choose between
>features and speed.
>4) In a multi-track environment, would there be any efficiency gains by
>increasing buffer size to accommodate only those tracks with a heavy
>plugin load while maintaining alignment of all tracks by simply delaying
>the start time of the other tracks?
good questions. i'll muse upon them, and I think others will too.
--p
This archive was generated by hypermail 2b28 : Sat Apr 22 2000 - 06:56:23 EEST