RESOLVED WONTFIX94520
Change min allowed sample rate in AudioBuffer to allow Android to work 
https://bugs.webkit.org/show_bug.cgi?id=94520
Summary Change min allowed sample rate in AudioBuffer to allow Android to work
Raymond Toy
Reported 2012-08-20 13:24:37 PDT
Change min allowed sample rate in AudioBuffer to allow Android to work
Attachments
Patch (5.51 KB, patch)
2012-08-20 13:27 PDT, Raymond Toy 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Raymond Toy
Comment 1 2012-08-20 13:27:12 PDT
Created attachment 159508 [details] Patch
Raymond Toy
Comment 2 2012-08-20 13:30:07 PDT
*** Bug 94516 has been marked as a duplicate of this bug. ***
Raymond Toy
Comment 3 2012-08-20 13:30:38 PDT
*** Bug 94519 has been marked as a duplicate of this bug. ***
Eric Carlson
Comment 4 2012-08-20 14:53:07 PDT
Why is 16000 Hz the magic minimum? Does it make sense for every port to have the same minimum sample rate, or should it be a compile time constant? Does the spec say anything about this? Should it?
Raymond Toy
Comment 5 2012-08-20 15:10:52 PDT
(In reply to comment #4) > Why is 16000 Hz the magic minimum? Does it make sense for every port to have the same minimum sample rate, or should it be a compile time constant? > Good questions. 16000 is currently the sample rate on Android. This effectively prevents createBuffer(nchannels, length, context.sampleRate) from working on Android. I don't have a good intuitive feeling if every port should have the same minimum or not. > Does the spec say anything about this? Should it? The spec (https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#AudioContext-section) says the sample rate must be "in at least the range 22050 to 96000." I hope Chris can comment on this.
Raymond Toy
Comment 6 2012-08-24 14:55:24 PDT
(In reply to comment #4) > Why is 16000 Hz the magic minimum? Does it make sense for every port to have the same minimum sample rate, or should it be a compile time constant? > > Does the spec say anything about this? Should it? An alternative approach. A grep through the code shows that AudioBuffers are always create with the sample rate of the AudioContext, except in AudioContext::createBuffer(). So we could move the test from AudioBuffer::create to AudioContext::createBuffer. The test can keep the current limits, but we can also add an additional test that says if the desired sampleRate matches the sample rate of the AudioContext, we're ok. This solves the issue, but I'm not sure it's a good idea that AudioBuffer::create no longer has a check for valid sample rates.
Peter Beverloo
Comment 7 2013-04-08 11:12:52 PDT
Resolving as WontFix given that Chromium moved to Blink.
Note You need to log in before you can comment on or make changes to this bug.