Re: oscillators and the Web Audio API

On Thu, Feb 9, 2012 at 11:40 AM, Chris Rogers <crogers@google.com> wrote:

> Ok, but you said that the ProcessedMediaStream implementation "spreads the
> processing for different streams across all available cores".  For the sake
> of argument, let's say that we have a chain of 6 ProcessedMediaStream
> objects and they're using 6 cores on an 8-core machine (one core/thread
> per ProcessedMediaStream).  That means that the kernel has to schedule 6
> threads one after the other SERIALLY!  This is with
> each ProcessedMediaStream thread getting scheduled (waking up), processing,
> then blocking/sleeping to wait for next available work, with the next
> stream in the chain taking the processed audio from the previous one.
>

My code currently does something even worse than that; another thread has
to run a control loop to hand the data from one ProcessedMediaStream to
another. But that's fixable, and the scenario you describe can be improved
on too. When we finish the onprocessmedia event for one Worker, we can have
that thread dispatch the onprocessmedia event for the next Worker without
yielding.

And, of course, every single Web Worker context could garbage collect at
> any time - in the worst cases two or more could gc serially with the delay
> being cumulative.
>

In practice, GC is totally insignificant in this model, because the heaps
of these Workers are tiny, typically a handful of objects.

In this example, I used 6.  But what if the number is hundreds or
> thousands?  Thousands may sound absurd, but I've created useful Web Audio
> code with this many using thousands of serially connected biquad allpass
> filters to generate interesting impulse responses.
>

That's impressive, especially if you can do it with low latency.

You're absolutely right that hundreds or thousands of independent Workers
won't scale, especially in series. ProcessedMediaStreams offers a couple of
options to get around that:
1) Fuse the thousands of serial filters into a single custom processing
node. Depending on the filters, this may give you the opportunity to do
extra optimizations (loop fusion, folding) as well.
2) Built-in effects. I think that support for JS effects needs to be as
good as it can be, but I've always agreed that some built-in effects will
be needed.


> Latency feels OK in my demos, but I haven't done anything to measure and
>> minimize it yet.
>>
>
> I believe the problems come up when dealing with more complex scenarios
> than your current demos.
>

I'm sure that's true.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not
in us. If we confess our sins, he is faithful and just and will forgive us
our sins and purify us from all unrighteousness. If we claim we have not
sinned, we make him out to be a liar and his word is not in us." [1 John
1:8-10]