- From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
- Date: Thu, 14 Jul 2011 09:44:03 +0300
- To: Chris Rogers <crogers@google.com>
- Cc: public-audio@w3.org
- Message-ID: <CAJhzemXbkOS+PSLcYZhQoKDpdmbw70HOKSZbvxiMJEdY6rynXw@mail.gmail.com>
> > 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