Skip to content
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

Caching Buffers? #19

Open
zz85 opened this issue Nov 29, 2011 · 3 comments
Open

Caching Buffers? #19

zz85 opened this issue Nov 29, 2011 · 3 comments

Comments

@zz85
Copy link

zz85 commented Nov 29, 2011

Hi, just wondering have anyone done any caching with audiolet?

For example, if you create a 1second sine wave, and were to play it back multiple times, would it possible to create a pre-calculated audio object? With this audio object, it could be more efficient to playback the object anytime you need without generating/calculating the buffers again.

@oampo
Copy link
Owner

oampo commented Nov 30, 2011

I haven't, but it should be possible as part of the planned BufferRecorder node - I talk a little bit about it in issue #11. The basic idea is that you could insert a BufferRecorder node somewhere in your processing chain and push a certain number of samples into it. When you have enough cached you would then disconnect everything from the BufferRecorder, and replace it with a looping BufferPlayer using the AudioletBuffer which you have been adding data to.

I haven't had time to have a proper go at creating the BufferRecorder but in theory it's pretty simple - just a buffer and a gate would do to start with. If you fancy having a go at it then I'll be happy to take a look at a pull request, and if you have any questions or issues then just post them up here.

@zz85
Copy link
Author

zz85 commented Dec 2, 2011

i'm new to all these audio stuff, but from what it seems needs to be done is to generate the waveforms and turn them into pcm wave, and then base64 encode them to be passed to an audio object? that's probably what sink.record() seems to be doing.

@oampo
Copy link
Owner

oampo commented Dec 5, 2011

Yeah, that would be a slightly different approach to achieving the same thing - each way of doing it has it's advantages and disadvantages. If you don't want to do any further processing on the audio then having it as an audio object would make sense as lots of the processing gets offloaded away from the JavaScript. If you still want to process the audio, just with some intensive processing cached then keeping everything with Audiolet as buffers makes more sense I think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants