Re: Requirements for Web audio APIs

You guys realize we're reinventing DirectShow, right? ;-)

On Mon, May 23, 2011 at 2:54 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> 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]
>



-- 
Ian Ni-Lewis
Developer Advocate
Google Game Developer Relations