Re: The future and direction of web audio

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