Subject: Re: [linux-audio-dev] Random thought on HDR latency compensation
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Fri Apr 21 2000 - 18:17:10 EEST
>a wonderful example for this is broadcast2000. it has a nice
>compressor that is "faster than the input" by pre-reading an
>adjustable number of samples before the "current" signal so
>that transients won't come through.
>applying it to one channel means apply it to all, else you
>get really weird phasing while monitoring.
This cannot be done in the way you describe using any plugin system
that I know of. You can't get samples from the input stream before the
current signal without using a delay line approach. OTOH, all
compressors that I know of keep a history of recent input, which as
far as I understand what you're describing is pretty much the same
thing.
Again, however, this has absolutely no effect on latency in any way
whatsoever.
>> Absolutely not. Plugins have no effect on latency whatsoever. Any
>> plugin system that allows this is incorrectly designed.
>
>how i would like to believe this !!
>if this is really possible, great.
>if not, an automatic delay to even out the latencies of each
>signal chain would come handy (could be the last plugin per
>default).
Let me repeat it again. Plugins have absolutely no effect on
latency. If the current chain of plugins takes longer to execute than
the time represented by the fragment/buffer size used by the
host/audio h/w then you have:
1) a drop-out
2) a non-real time system
3) both of the above
Under these circumstances, latency is simply irrelevant. It might be a
*problem* for you, but it has nothing to do with latency and
everything to do with dropouts.
The only exception I can think of is if the plugin chain somehow runs
more efficiently with a larger blocksize (which is often true), and
you or the plugins try to force the latency up in order to accomplish
this. However, this is merely a workaround for the basic problem that
you are trying to do too much computation in the available time, and
so you do not have a real-time system at the lower latency setting at
all.
All you could say in those circumstances would be that the particular
chain of plugins in use cannot be used as a real-time system with
latencies less than N msec. But that doesn't mean that a less
demanding chain of plugins actually affects the latency of the system
- it just means that its fast enough to be executed given the latency
of the system.
>i think a good daw should allow for non-realtime
>processing...
No doubt about that, but this is completely irrelevant if you're
playing back a "tape" of pre-recorded (and possibly edited) material
and/or recording to the said tape. Recording and playback *are*
real-time processes, and as such, they must do the right thing. If you
want to go in afterwards and time-shift a particular track or section
of a track in a non-realtime way, be my guest, but thats not part of
the recording/playback process.
--p
This archive was generated by hypermail 2b28 : Fri Apr 21 2000 - 18:52:47 EEST