Allow OfflineAudioContext to render smaller chunks repeatedly about web-audio-api-v2 HOT 9 CLOSED

We're thinking this could go in the direction of allowing an offline context to complete the filling of its buffer, but then be restarted (seamlessly) with a new buffer instead of becoming dead. Making these buffers relatively short allows the rendering to be chunked and/or easily terminated without holding onto a lot of memory.

from web-audio-api-v2.

F2F resolution, two things:

• Either have a new method (abort()?) or repurpose close() to terminate the rendering early.
• Integrate with WHATWG Streams to be able to stream the rendering of PCM data to something else. This would work by outputting 128 frames buffers, and the final one potentially less than 128 frames (depending on the number of frames requested initially).

from web-audio-api-v2.

WG question: Would you want to access the data computed up to the point at which the context is closed?

from web-audio-api-v2.

FWIW, I would like the rendered audio. I think this complicates things a bit in figuring out what the startRendering promise should do.

from web-audio-api-v2.

For our use case here, it's not immediately necessary at the moment to resolve with the already rendered data, we are just looking for the cancel portion of this functionality (for us the best approach would be streaming to a file through an encoder directly anyways, to avoid the memory impact, but to the best of my knowledge, we are currently way too undermanned to pull that off).

However, I believe returning a Promise<AudioBuffer> that resolves with what's already been rendered would be a sound decision perhaps:

let partiallyRenderedResults: AudioBuffer = await audioContext.stopRendering();

Although I'm not sure if this would be efficient, as AFAIK (most?) implementations pre-allocate the full length AudioBuffer that is ultimately acquired at the end of startRendering, which perhaps means a new allocation for the partial results would be required? (I'm not quite sure about this without digging into an implementation right now)

Edit

Of course we can always just resolve with an already allocated AudioBuffer, but this would then require a way to reliably access the exact sample point up to which rendering was done. Perhaps this could be done by speccing currentTime to be the time-representation of this exact value? This would in theory allow computing the last valid sample point, e.g. by doing:

let partiallyRenderedResults = await audioContext.stopRendering();
let lastValidSampleIndex = Math.floor(audioContext.currentTime * audioContext.sampleRate);

Edit 2

Acquiring partial results through stopRendering would pose a question about what happens to startRendering. Perhaps it would be reasonable if it also resolved with the partial results?

from web-audio-api-v2.

perhaps running the rendering process in an iframe`, which can be reloaded without reloading my entire app.

I tried implementing this, but in my tests, the iframe doesn't reload until after the OfflineAudioContext completes rendering. Have you gotten this to work?

from web-audio-api-v2.

I tried implementing this, but in my tests, the iframe doesn't reload until after the OfflineAudioContext completes rendering. Have you gotten this to work?

This sounds like an implementation issue, maybe open a bug on the relevant implementation bug tracker?

from web-audio-api-v2.

See also #66

from web-audio-api-v2.

Closing this. #66 should be able to handle early termination since we're incrementally delivering audio. Just need to add some kind of close method to indicate that the offline context is done.

from web-audio-api-v2.