New issue
Advanced search Search tips
Starred by 44 users

Issue metadata

Status: Duplicate
Merged: issue 432248
Owner: ----
Closed: Dec 2015
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Feature



Sign in to add a comment

Allow choice of sample-rate in AudioContext constructor

Project Member Reported by crogers@google.com, Feb 15 2011

Issue description

Currently the AudioContext has a fixed sample-rate which can't be chosen by the developer.  A new sample-rate constructor argument could be added to AudioContext.
 

Comment 1 by crogers@google.com, Feb 15 2011

Grant, I would like to understand much more detail about how your code works to see if there are other fairly simple solutions. It is usually possible to adapt synthesis and processing code to run at arbitrary sample-rates, thus it should be possible to look at context.sampleRate and adjust rendering accordingly.

Comment 2 by karen@chromium.org, Feb 15 2011

Labels: Mstone-12

Comment 3 by crogers@google.com, Apr 4 2011

Labels: -Pri-2 -Mstone-12 Pri-3 Mstone-13

Comment 4 by crogers@google.com, May 19 2011

Labels: -Mstone-13 Mstone-14
A good approach in my opinion, is well, as probably known, not the most performance-wise, but I think it's a very flexible solution. So I think that when you create a JS Processing Node, it should be able to take a sample rate argument, forcing the context to do the resampling, and if it's not specified, it should use the context's sample rate. That's the case that pure JS processing needs, but... I also think that the developer should be able to specify the sample rate of the context as well, because it doesn't matter if you have one source and one sink, and their sample rates don't match, that's something that might happen anyway in the backend, but in the case of JS processing nodes combined with the other nodes, it can get pretty hairy if one element is in different sample rate than all the others. What I personally want, and I think that's good for long term as well, is freedom to do stupid things. When our computer's have 100x better performance with grafene processors coming out (sarcasm involved), we're going to regret taking away freedom to get performance.

Is there a way to cc this to the working group?
Seems that Grant isn't that active on this, so I'll fill in some details...
In grant's case, he has a source that is of a fixed sample rate, because he's running a virtual machine, and the code that runs on the machine expects the sample rate to be a fixed 70khz or so, making it either 1) a resampling matter 2) a matter of making the virtual machine run slower, which is not nice, because it's running games 3) a matter of buffer overflow :)

Comment 7 by crogers@google.com, Jun 23 2011

 Issue 86767  has been merged into this issue.

Comment 8 by crogers@google.com, Jun 23 2011

Both Grant and Jussi have use cases where this would be useful.  This is not a simple fix as the sample-rate conversion involves some subtlety in how the buffering (uniform buffer sizes) work, and can affect performance since it will cause graph per-quantum processing to occur at non-uniform time intervals.  This reduces the maximum amount of work that can be done per render quantum.

When this feature is added, there needs to be very clear documentation that choosing a non-hardware sample-rate will adversely affect performance, and that it is discouraged except in specific cases where it is truly required.

Comment 9 by k...@google.com, Jul 28 2011

Labels: -Mstone-14 Mstone-15 MovedFrom-14
Punting out non-critical bugs.  Please move back to 14 if you believe this was done in error.
Well, I was hoping to see this in 14... can we get a status update on this? As Chris said it's not a trivial fix, but in our mail exchange Jussi, Chris and I pretty much agreed that it was very useful.

I'd be happy to get involved and propose a patch for this (would just need a few days to jump in to the code) and then Chris can review the changes and accept/reject/correct the patch. How's that for an idea? :)

Comment 11 by crogers@google.com, Jul 28 2011

Hi Amos, the code for this will go into WebKit.  So the first thing to do would be to try to get a patch landed in WebKit.  After it's landed there, then it would need to be approved for merging into the M14 WebKit branch - or deferred to M15.  Regardless of whether it makes M14, it would start appearing in Canary builds very soon after landing in WebKit.  We can discuss changes that would need to happen in WebKit offline if you're interested in taking this on...

Comment 12 by kareng@google.com, Sep 8 2011

Labels: MovedFrom15 bulkmove Mstone-16
moving all non-essential bugs from 15 to 16. please feel free to move back if this was an error and your bug is a release blocker.

Comment 13 by laforge@google.com, Oct 24 2011

Labels: -Mstone-16 MovedFrom-16 Mstone-17

Comment 14 by k...@google.com, Dec 19 2011

Labels: -Mstone-17 Mstone-18 MovedFrom-17
Moving bugs marked as Available but not blockers from M17 to M18.  Please move back if you think this is a blocker, and add the ReleaseBlock-Stable label.  If you're able.

Comment 15 by Deleted ...@, Jan 12 2012

what if the sample rate in the browser dose not match to the sample rate of the sound card?

I have this bug with a E-MU 1212m sound card


In the mean time, I have a fast linear interpolation algorithm that can do 256 khz stereo in less than 1% CPU usage on a lappy (Did a CPU profile on my JS GBC emulator with 256 khz stereo audio.): https://github.com/grantgalitz/XAudioJS/blob/master/resampler.js

It's used for web audio and flash for where resampling isn't supported by the browser (Like in this case).
Also, it handles the tail cases, so writing later to the resampler "continues" the stream interpolation properly.
crogers: I have to sample to a high number, because that's what's necessary for proper emulation of the audio state. No way around it.
Internal counters have to have high precision for proper audio length clock-downs. Also, the WAV RAM of a gameboy can be specified to have an internal sample rate of over 100 khz. And many effects are done to the clock cycle (4.194304 MHZ, 512 KHZ internal audio logic for counters).
The MediaStream API by roc allows an arbitrary sample rate to be specified by the developer, so that will cause further problems until the capabilities of boths APIs are finally aligned.
crogers: Check for any audio bugs other people report other than me that involve the JS GBC emulator. I'm getting a lot of complaints (Broken audio on chrome stable/beta/canary) after it went viral on Stumbleupon.
Though, web audio seems to work on Windows 7 and mac os x snow leopard, I know WinXP has some stutter issues and lots of random audio gaps.
I really should be sampling at just over 2 MHZ and using a Sinc resampler for my emulator. Tried that, and V8 easily overloads, so I had to compromise and do 256 khz stereo audio with linear interpolation. :/
Don't use the contemporary Java-based GBC emulators for load comparison, as emulators like MeBoy/JavaBoy/vGBX/GBCOnline don't actually emulate the audio well and are actually highly inaccurate with clock cycle accuracy and straight sample off 44.1 khz. Proper emulation would be more of Gambatte (Which is C++ based). VisualBoyAdvance actually is almost as bad as the Java ones, but slightly more clock cycle accurate.

Comment 25 by kareng@google.com, Feb 7 2012

Labels: MovedFrom18 Mstone-19

Comment 26 by bakt...@gmail.com, Mar 2 2012

Adding a new Resampler AudioNode type is not a better solution?

It resolves the problem and, as a plus, it can also be combined with the rest of the AudioNodes which is an interesting feature. 
That would make sense. Also being able to select the resampling algorithm would be a bonus.

Comment 28 by laforge@google.com, Mar 27 2012

Labels: -Mstone-19 Mstone-20 MovedFrom-19

Comment 29 by k...@google.com, Apr 27 2012

Labels: -Mstone-20 Mstone-21 MovedFrom-20
We're too close to the branch point for any more Pri 3 bugs.  If you believe one of these needs to be in M20, please adjust the mstone and priority.
Update: I actually sample internally at 4194304 Hertz Stereo now, and tricked the V8 engine into optimizing it. I resample down entirely in js with a custom resampler that doesn't skip samples like a normal linear interpolation. I wrote a custom resampler in js that can interpolate with more than two sample inputs at a time. If I'm going to use a resampler node provided by web audio, it must be at least of the quality I'm using. I had to work around the problem of mozilla audio providing only a linear interpolation algo by resampling internally inside js with a first pass resampler.

Comment 31 by kareng@google.com, Nov 20 2012

Labels: -Mstone-21 MstoneRemoved
Bugs that have been moved 5 or more times. Removing Mstone label.

Comment 32 by kareng@google.com, Nov 20 2012

Bugs that have been moved 5 or more times. Removing Mstone label.
Project Member

Comment 33 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-WebKit Cr-Content
Project Member

Comment 34 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink
Any tips for how we can downsample recorded audio using Recorder.js? (https://github.com/mattdiamond/Recorderjs/blob/master/recorderWorker.js#L97)

Also, in the code below, it seems I can never change sampleRate from 44100 without getting an "Error: SyntaxError: DOM Exception 12" - Any workarounds for this?

var sampleRate = 44100;
var lengthInSeconds = 3;
var context = new webkitOfflineAudioContext(1, sampleRate * lengthInSeconds, sampleRate);
Hi, any ETA on this issue?
Hello, I am also curious if there is an ETA for this. Thank you
I'm looking for this to be fixed so the output can be used as digital output via devices that look as sound cards. I'm using it in a function generator, defining the waveform and sample rate is needed for proper temporal rendering.
Labels: -Cr-Blink Cr-Blink-WebAudio
Owner: ----
Status: Available
 Issue 356312  has been merged into this issue.

Comment 41 by rtoy@chromium.org, Jun 3 2015

Re #35: Offline contexts support sample rates from 3 to 192 kHz.
Re #36, #37: No eta.  We'd need some general consensus from the W3C webaudio group on how to specify the sample rate for an AudioContext.  There has been general agreement that this is useful, but it hasn't been decided how this should be done.
FWIW, this issue is related to this spec: http://w3c.github.io/mediacapture-output/

The spec itself needs a lot more work (currently it is very rudimentary), but the point is all the device-specific arrangement should be handled by this API and AudioContext simply accepts the configuration object at its instantiation.

As @rtoy pointed out, this needs some discussion on this issue in W3C AudioWG and other groups.

Comment 43 by rtoy@chromium.org, Dec 11 2015

Mergedinto: 432248
Status: Duplicate
Duplicating to issue 432248, where we'll keep track of the audio context resampling issue, which is now part of the spec.

Sign in to add a comment