On Sat, Aug 4, 2012 at 10:53 AM, Chris Rogers <crogers@google.com> wrote: > Peter, as Jussi has pointed out. This is a sad fact of life and "not a > bug". If you read more carefully what Jussi says, this lag/latency is not > something we can somehow fix by creating a different API. This is the way > that a real-time audio thread interacting with a main thread (which can > have its own delays such as garbage collection) must be. It's a law of > physics. On the contrary, you can have high-latency processing nodes (e.g. JS workers with a high context switch time, large-window ducking effects) without introducing lag, *if* you can precompute the values of their inputs far enough ahead in time. Then you can run the high-latency nodes early and get the results in time to play them. MSP did this. I think for Peter's application this would be a fine approach. However, it's true you can't always do things that way. Precomputation requirements add latency to interactive graph changes and to "live" graph inputs (e.g. getUserMedia). Cycles with low internal delay also limit precomputation within the cycle. Precomputation adds complexity, and for the sake of implementing the current Web Audio proposal I've dropped support for precomputation internally for now. However, I think in the future we'll want to support an MSP-like precomputation regime for parts of the audio graph where it's needed. I'm unsure of the best way to expose it to authors though ... handling situations where features conflict is tricky. Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others?" [Matthew 5:43-47]
Received on Saturday, 4 August 2012 05:30:58 UTC