Re: [linux-audio-dev] Random thought on HDR latency compensation

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Random thought on HDR latency compensation
From: Jörn Nettingsmeier (nettings_AT_folkwang.uni-essen.de)
Date: Mon Apr 24 2000 - 00:00:10 EEST


Paul Barton-Davis wrote:
>
> >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.

ok. i see the term latency is not appropriate here.

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

thank you for the clarification. i was stupidly thinking about one
plugin using 60% cpu time and another using, say 50% (total >100%),
but of course a delay won't earn us much here.... ~%-]
  
yours,

jörn

-- 
Jörn Nettingsmeier     
Kurfürstenstr. 49        
45138 Essen, Germany      
http://www.folkwang.uni-essen.de/~nettings/


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sun Apr 23 2000 - 23:39:41 EEST