Fwd: TPAC F2F and Spec Proposals

Sorry, I always forget to reply all.

---------- Forwarded message ----------
From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Date: Tue, Oct 18, 2011 at 4:23 PM
Subject: Re: TPAC F2F and Spec Proposals
To: Anthony Bowyer-Lowe <anthony@lowbroweye.com>


On Tue, Oct 18, 2011 at 3:52 PM, Anthony Bowyer-Lowe <anthony@lowbroweye.com
> wrote:

> If we take effects out from Web Audio API, what are the main differences
>> between MediaStream API and Web Audio API, and
>> are there reasons to have two separate APIs to process audio?
>>
>
> There are few differences for the processing audio use cases such as
> providing spectral visualisations of playing music, or echo cancellation of
> webcam calls. The MediaStream API is very satisfactory for this.
>
> However, for the purposes of realtime synthesis & sample playback and
> videogame audio feedback, where low latency, low jitter sound
> generation/triggering and direct user interaction are required then the Web
> Audio API's focus upon canonical audio formats and strong timing make it far
> more useful than the MediaStream API which offers none of these
> capabilities.
>
>
> Anthony.
>

I beg to differ here, as the media stream API offers the sample level
access, so there are no boundaries per se, other than those of hardware
limitations and JS speed, take a look at http://jams.no.de , it's pure JS
generated music with no native effects whatsoever, made to work with the
current Audio Data API and Web Audio API. It works quite seamlessly
especially considering it's running the graphics and audio in the same
thread, which is something you really shouldn't do. This is in my opinion
actually a flaw in the current implementations of the aforementioned APIs,
you can't take the audio processing into another thread, but that is
possible, and in fact the only way, in Media Streams API. The example demo
could quite easily be changed to work with Media Streams API, thus making it
much more efficient.

Jussi