W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2011

Re: The future and direction of web audio

From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Date: Thu, 14 Jul 2011 09:44:03 +0300
Message-ID: <CAJhzemXbkOS+PSLcYZhQoKDpdmbw70HOKSZbvxiMJEdY6rynXw@mail.gmail.com>
To: Chris Rogers <crogers@google.com>
Cc: public-audio@w3.org
> Concerning sample-rates, the range I'm thinking could be quite large such
> as 11KHz to 384KHz, but at some point when you're writing code in C or C++
> which can crash, lock up the machine, or have security issues then you have
> to protect against wild values such as 10000000KHz and so on.  Believe me,
> we're very conscious of such possibilities as browser implementors.

I'm sorry, I was a bit radical about that, not mentioning the security
issue. I think 384khz is - well - quite enough for the time being. :D

> These values can vary depending on implementation (but must support at
> least a certain amount) and can be accessed something like this:
> glContext.getParameter(glContext.MAX_TEXTURE_SIZE);

That's a good idea. Another handy parallel solution could be
AudioContext.canPlayAtRate(sampleRate) (What a stupid name for a function,
please don't take the name idea) which - similarily to <audio>.canPlayType()
would return "yes", "maybe" or "no" according to the algorithms the browser
uses to detect the optimal sample rates. This would allow the developer to
do an application, where (s)he *wants* 96khz, asks whether it can be done
and thinks, "ok this is really important for the application" (why??) then
he will use it if it's a "yes", and take his chances even if it's a "maybe",
and if it's a no, go for 48khz. This would actually make more sense to me
than the <audio>canPlayType, where maybe means "I probably don't have the
decoder" (especially in the case of Chromium). ;)

> The good news is that the limits on sample-rate can be quite huge to allow
> for just about any conceivable application, and this range could be extended
> as necessary in the future (without changing API).  I'm not suggesting an
> API which locks us into anything, but individual implementations will have
> limits.  We can use WebGL as a guide for how such limits are handled.

Changing values as the computers get more powerful is a reasonable solution
to me. Such a thing just needs to be documented. :)
Received on Thursday, 14 July 2011 06:44:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:49:56 UTC