Re: Concerning the gap-less output of real-time generated audio in JavaScript

>
> Yet another approach is to directly request the audio destination node to
> pre-buffer N samples, which has the effect of requesting its source nodes
> (and consequently their attached graph of dependents) to provide those
> samples. This may be easier since it doesn't affect the audio graph on a
> piecemeal basis, doesn't raise issues of how to time-sync "immediate" writes
> and pipelined writes, and addresses the general (and probably occasional)
> need to pre-buffer some time interval based on application knowledge.
>

IMO, that is a very desirable feature as well.

I endorse supporting a blend of approaches (some developer control on
> buffering, layered on a robust automatic pipeline).  As a corollary I don't
> think that either approach alone is a cure for all ills.
>

My opinion lines very well with that. I'm also all in for as modular as
possible approach for this kind of API, after all, I don't think any of us
wants to rewrite thing in JS just to change a simple behaviour (such as the
resampling method of the AudioBufferNode).


> My experience is that there is generally no way in a complex runtime
> environment to outright prevent glitches, regardless of how much programmer
> smarts are in control of buffering. Also, just as developer-written code can
> "know" things about what the app environment is doing, a self-regulating
> callback method is able to "know" things about the what the internal browser
> environment is doing. Both types of knowledge are important.
>

Agreed.


>
>

> ... .  .    .       Joe
>
> *Joe Berkovitz*
> President
> Noteflight LLC
> 84 Hamilton St, Cambridge, MA 02139
> phone: +1 978 314 6271
> www.noteflight.com
>
>
Cheers,
Jussi