Should copyToChannel accept a shared Float32Array?

[kettle11]

Presently calling AudioBuffer: copyToChannel(source, channelNumber) with a source backed by a SharedArrayBuffer is disallowed. In Chrome you get the following crash: Failed to execute 'copyToChannel' on 'AudioBuffer': The provided Float32Array value must not be shared.

This is a footgun when working with WebAssembly. Creating a Float32Array backed by the Wasm memory and passing that in to copyToChannel works fine unless the Wasm memory is backed by a SharedArrayBuffer.

This has resulted in bugs like this one, which impacts a popular audio library from the Rust ecosystem: RustAudio/cpal#656

Should calls like copyToChannel be allowed to accept shared Float32Arrays or is it necessary to forbid them?

[padenot]

That sounds like a reasonable addition.

That said, cpal's code is really inefficient and should use SharedArrayBuffer and a ring buffer, as explained in https://blog.paul.cx/post/a-wait-free-spsc-ringbuffer-for-the-web/. https://crates.io/crates/ringbuf/ is a nice one in rust.

[hoch]

From teleconference:

1. Copying the data into an active buffer is not allowed according to "acquire content" process.
2. Chromium doesn't have a complete implementation of this feature yet. (WPT)

Next steps:

1. Figure out if this is possible on each browser implementation. If this is not really feasible, we need more discussion.