You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Presently browser's will crash if copyToChannel(source, channelNumber) is called with a Float32Array that is backed by a SharedArrayBuffer. I opened an issue on that here: WebAudio/web-audio-api#2565
While the browser's copyToChannel function accepts a Float32Array as the source argument web-sys instead takes in a &[f32]. This is likely for convenience but it also makes it impossible to use web_sys's copy_to_channel in cases where the Float32Array was acquired from a source that's not the Wasm instance's memory. This seems like an API oversight to me.
This limitation means that if the memory is backed by a SharedArrayBuffer copy_to_channel simply cannot be used without causing a crash.
That makes workarounds, like the one required for this issue: RustAudio/cpal#656, a little messier.
Workarounds are possible but it also seems like the web_sys API should consider changing.
The text was updated successfully, but these errors were encountered:
Agreed, probably all methods which take a view should probably also generate a function which takes an appropriate array buffer. I think it would be nice to figure out a way to pass both at the same time (e.g. with a trait), but that would be a breaking change.
Additionally, to fix the current behavior, it might be good to guard this method behind a cfg(not(target_feature = "atomics")).
Presently browser's will crash if
copyToChannel(source, channelNumber)
is called with a Float32Array that is backed by a SharedArrayBuffer. I opened an issue on that here: WebAudio/web-audio-api#2565While the browser's
copyToChannel
function accepts aFloat32Array
as thesource
argumentweb-sys
instead takes in a&[f32]
. This is likely for convenience but it also makes it impossible to useweb_sys
'scopy_to_channel
in cases where theFloat32Array
was acquired from a source that's not the Wasm instance's memory. This seems like an API oversight to me.This limitation means that if the memory is backed by a SharedArrayBuffer
copy_to_channel
simply cannot be used without causing a crash.That makes workarounds, like the one required for this issue: RustAudio/cpal#656, a little messier.
Workarounds are possible but it also seems like the
web_sys
API should consider changing.The text was updated successfully, but these errors were encountered: