Re: Requirements for Web audio APIs

On Tue, May 24, 2011 at 5:42 AM, Chris Rogers <crogers@google.com> wrote:

> Rob, I'm afraid I'll just have to strongly disagree.  The Stream API is
> designed specially for peer-to-peer communication.  Superficially it has
> sources and sinks of data like the Web Audio API, but if you really read
> both specs carefully their design goals are quite distinct. The Web Audio
> API has had a great deal of care in its design to address a variety of use
> cases for client side games, music, and interactive applications.  The
> Stream API does not replace its functionality.  Does it have the concept of
> intermediate processing modules, routing graphs, implicit unity gain summing
> junctions, fanout support, channel mix-up and mix-down, sample-accurate
> timing, among many other design features? -- no it does not.


Indeed. And the Web Audio API does not have support for capturing local
audio, recording and compressing processed audio, or sending processed audio
over the network (and we have only a sketch for how it might handle A/V
synchronization). We need fix to these deficiencies in both specs by
bringing them together somehow.

If we persist with the approach that Web Audio handles one set of use-cases
and Streams handle a different set of use-cases, we'll be making life
unnecessarily difficult for authors whose use-cases need features from both
specs. See for example the scenarios here:
https://wiki.mozilla.org/MediaStreamAPI#Scenarios
At least #3, #4, #5, and #6 require functionality that is currently split
across both proposals --- and I'm sure people can think of more creative
ways to mix and match features.

These are both only proposals. Now is the time to make changes to avoid
future problems. This is why we have a standards process.

The Web Audio API has implementations, working examples and demos, showing
> it to be viable in solving the problems it was designed for.  The Stream API
> is in a much earlier stage, and although I believe it will be successful for
> what it was designed, it's extremely unlikely that we'll be seeing it
> running the same kinds of audio applications as the Web Audio API.


In its current form, yes. But I see no fundamental reason why the
functionality of the Web Audio API can't be provided by modifying and
extending the Streams proposal.

Another option would be to merge Streams functionality into Web Audio, but
since Streams need to contain video, at least the nomenclature would need to
change.

Rob
-- 
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]