-
Notifications
You must be signed in to change notification settings - Fork 168
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AudioBuffer should not be tied to a context #370
Comments
But even with the resampling by decodeAudioData, the resulting AudioBuffer should be shareable. Also, see Issue #30. |
This is actually going to happen in v1, as part of #250. |
I am reopening, moving to V1 and marking as needing discussion because it probably didn't happen in the way that @cwilso expected: the current |
Yeah, not sure why AudioContext is needed at all here? |
Yeah, let's remove this. I think we just forgot about this issue when defining the constructor. So, something like
but |
Hi, thanks for the awesome work, and sorry for comment on a cloosed issue, but I have a question: Does it means that in next version of WAA we will be able to create a buffer using the constructor instead of AudioContext's factory function?: var buffer = new AudioBuffer(length, 44100);
buffer.copyToChannel(myArray); Thanks |
On Tue, Jan 10, 2017 at 8:42 AM, danigb ***@***.***> wrote:
Hi, thanks for the awesome work, and sorry for comment on a cloosed issue,
but I have a question:
Does it means that in next version of WAA we will be able to create a
buffer using the constructor instead of AudioContext's factory function?:
Yes.
var buffer = new AudioBuffer(length, 44100);
But it would look more like:
var buffer = new AudioBuffer({length: length, sampleRate: 44100});
…--
Ray
|
Great news! Thanks for the answer @rtoy ! |
AudioBuffers shouldn't really be tied to an AudioContext*. Therefore, AudioBuffers should have a constructor that works - i.e. "context.createBuffer(2, 88200, 44100);" should turn into "new AudioBuffer(2, 88200, 44100);"
*except when they're created by decodeAudioData - and even that shouldn't be "tied" to an AudioContext - i.e. I think they should be shareable - but the context currently resamples. We should also make decodeAudioData have a flag that disables the resampling.
The text was updated successfully, but these errors were encountered: