Re: DynamicsCompressorNode and latency

On 6 Jul 2012, at 02:54, Robert O'Callahan wrote:

> In http://www.w3.org/2012/05/30-audio-minutes.html Chris R said: "The dynamics processer has a small look-ahead latency."
> This small remark has large implications. No other node does any kind of lookahead or latency compensation right now. Supporting lookahead causes problems when you have cycles (depending on the total delay around the cycle(s) compared to the total lookahead in the cycles). There are also issues where a node doing lookahead has looked ahead in some source stream, and then something changes in the graph which means the data it looked it isn't actually valid anymore. (Given that chaining nodes with lookahead can require arbitrary lookahead on a source node, a whole host of issues would arise.)
> 
> It had seemed to me that Web Audio was designed around the assumption that the output of a node for sample T could only depend on the values of its input nodes at samples T' <= T. 

I'm not sure I understand how this look-ahead is any different from (and thus more problematic than) the buffering (and thus the delay) created by the JavaScriptNodes? 

https://en.wikipedia.org/wiki/Dynamic_range_compression#Look-ahead
«Look-ahead is a misnomer in that the future is not actually observed. Instead, the input signal is split, and one side is delayed. The non-delayed signal is used to drive the compression of the delayed signal, which then appears at the output. This way a smooth-sounding slower attack rate can be used to catch transients. The cost of this solution is that the signal is delayed.»

Olivier