W3C home > Mailing lists > Public > public-xg-audio@w3.org > December 2010

Re: Making Web Audio APIs More Competitive with native

From: Kumar <srikumarks@gmail.com>
Date: Sat, 11 Dec 2010 12:39:23 +0800
Message-ID: <AANLkTikEvugLqQKWz_4YUj9-EgdpTQCd9Btwduh-fd_O@mail.gmail.com>
To: Chris Rogers <crogers@google.com>
Cc: Noah Mendelsohn <nrm@arcanedomain.com>, public-xg-audio@w3.org, Doug Schepers <schepers@w3.org>
Hi Chris,

Yes, you're right about the immaturity of OpenSL ES. It is a
relatively recent spec indeed. OpenAL (together with EFX) is
a more mature candidate.

The symmetry I was referring to is more about the broad
principles behind considering existing APIs ... three of them -

1) Reducing developer cognitive load in the long run,
2) Maximizing audio hardware access in the long run and
3) Reducing browser implementation burden in the long run.

On various platforms, we have OpenAL, Core Audio,
DirectSound, OSS, ALSA, ESD, JACK, LADSPA. Of these,
possibly OpenAL has the widest base. If we're to look a couple
of years into the future, I can't help wonder if OpenSL ES
will be the more established native API. It is certainly getting
on to Android [http://developer.android.com/sdk/ndk/overview.html].

If OpenSL ES is prevalent on mobile platforms and it can
wrap around existing platform-specific audio APIs and codecs,
then having its object model directly available via Javascript
seems likely to maximize the audio hardware access across the
board. Given that platform vendors will provide the implementation,
adopting it will reduce the implementation burden on WebKit/Mozilla,
and reduce the need for developers to work with one more audio API
in the mix.


On Sat, Dec 11, 2010 at 2:34 AM, Chris Rogers <crogers@google.com> wrote:
> Hi Kumar,
> There's a big difference between OpenGL and OpenSL.  OpenGL is a mature API
> which has existed for a long time, has many implementations supporting it,
> and lots of code written for it.  OpenSL is a much newer proposal which
> doesn't have these features.  Other than the name being similar to OpenGL, I
> don't think there's anything particularly "symmetric" about it.
> Chris
> On Thu, Dec 9, 2010 at 10:00 PM, Kumar <srikumarks@gmail.com> wrote:
>> Hi all,
>> I joined the public forum relatively recently and
>> I've been reading this thread with great interest.
>> The work on the audio API thus far is impressive.
>> That said, I couldn't help wonder whether some of
>> the initiatives in other standards groups can be
>> merged into this effort - particularly that of
>> OpenSL ES (http://www.khronos.org/opensles/)
>> That would make the audio path symmetric compared
>> to what the visual group is doing with WebGL, which
>> is taking OpenGL ES and making it available via
>> a JavaScript API built atop Canvas 3D.
>> Any thoughts on this? On first glance, there doesn't
>> seem to be anything particularly limiting about
>> OpenSL ES (to me at least) that would make it
>> inappropriate for web use. I hope to get a better
>> idea of it in the coming days.
>> Anyone here who straddles both groups?
>> Regards,
>> -Srikumar
>> On Fri, Dec 10, 2010 at 3:28 AM, Noah Mendelsohn <nrm@arcanedomain.com>
>> wrote:
>> >
>> >
>> > On 12/9/2010 2:12 PM, Chris Rogers wrote:
>> >>
>> >> I don't expect that a JavaScript developer is going to play with my API
>> >> for
>> >> a couple of weeks and come back with Digital Audio Workstation software
>> >> to
>> >> rival something like Apple's Logic Audio
>> >
>> > Indeed, but if we set off down the path that would lead to such things
>> > in,
>> > say 5 years, with interesting DAWs of lesser capability emerging along
>> > the
>> > way, that would be really wonderful.  I'm actually curious what will
>> > prove
>> > to be implementable in Javascript over time from a performance point of
>> > view.  E.g. it's very cool that Javascript is doing FFts with plausible
>> > performance today, but it will be interesting to see when it can do 20
>> > in
>> > parallel on a many core chip.  Still, this all looks very, very
>> > promising.
>> >  Thanks!
>> >
>> > Noah
>> >
>> >
>> >
Received on Saturday, 11 December 2010 04:52:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:37:59 UTC