Re: Adding Web Audio API Spec to W3C Repository

On Thu, 09 Jun 2011 23:46:33 +0200, Robert O'Callahan  
<robert@ocallahan.org> wrote:

> We (Mozilla) definitely plan to put forward a new spec that builds on the
> HTML Streams proposal. I would like to make more progress on the
> implementation before we do that, but if you think otherwise, we can go
> forward.
>
> I believe the concerns I raised about synchronization and the  
> relationship
> with the Streams proposal that I raised in the earlier thread are still
> valid, but that thread was a tennis match between me and Chris and I'd  
> like
> to hear from W3C people and other parties (especially HTML and Streams
> people) how they feel about those concerns.
>
> As a veteran of decade-long efforts to resolve conflicts between specs  
> that
> never should have happened in the first place (SVG, CSS and HTML, I'm
> looking at you), I think it's worth taking time to make sure we don't  
> have
> another Conway's law failure. The immediate demand for audio API will  
> have
> to be (and is being) satisfied by libraries that abstract over browser
> differences, and that will remain true for quite some time no matter what
> the WG does.

Hi roc, everyone,

I've been regrettably silent on this list so far, but an Audio API is  
something that we (Opera) certainly want to support, so getting it right  
is of course important to us.

It was quite some time since I looked at  
<http://chromium.googlecode.com/svn/trunk/samples/audio/specification/specification.html>,  
so I hope this is still the correct version to look at. My gut reaction to  
this spec has always been "too big" and "you ain't gonna need it".  
However, it's hard to argue with something that's being implemented  
without having a better proposal, so I've stayed silent.

About https://wiki.mozilla.org/MediaStreamAPI then...

This looks quite promising to me, and I'm looking forward to seeing a  
proof-of-concept implementation. Since implementing HTML5 multitrack,  
video conferencing and adaptive streaming will require quite a bit of  
internal media framework plumbing, it would be good if the Audio API maps  
more directly to the concepts used there, which is the Stream object. So,  
roc's proposal certainly feels more native to and integrated with the rest  
of the HTML media stack, which was of course the main objective, so that's  
no surprise.

As for declarative vs scripted, I guess what this comes down to is  
latency. Which kinds of effects are strictly necessary to have dedicated  
filters for, and which are not? Not knowing the answers, starting out  
simple and adding filters only when needed seems a good approach to me.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Friday, 10 June 2011 07:50:11 UTC