The panic occurs because cpal can now place the Firewheel processor in an audioworklet (multi-threaded processing). However, in the cpal backend, we're making a call to Instant::now.
|
let process_timestamp = bevy_platform::time::Instant::now(); |
This works great on the main browser thread, but cannot be called within the audio worklet. Instead, we'd need the timestamp provided by the worklet itself, which is what firewheel-web-audio uses. cpal provides this timestamp for the audioworklet host:
https://github.com/RustAudio/cpal/blob/078787ee8061c41fc3198e3a39d55238bc68fa4d/src/host/audioworklet/mod.rs#L325
I believe there was a rationale at some point for not using cpal's timestamps. Does that still hold? If so, I think we should make an exception when the audioworklet feature is enabled. I can make a PR to provide this behavior.
The panic occurs because
cpalcan now place the Firewheel processor in an audioworklet (multi-threaded processing). However, in thecpalbackend, we're making a call toInstant::now.Firewheel/crates/firewheel-cpal/src/lib.rs
Line 1029 in 981b9b3
This works great on the main browser thread, but cannot be called within the audio worklet. Instead, we'd need the timestamp provided by the worklet itself, which is what
firewheel-web-audiouses.cpalprovides this timestamp for the audioworklet host:https://github.com/RustAudio/cpal/blob/078787ee8061c41fc3198e3a39d55238bc68fa4d/src/host/audioworklet/mod.rs#L325
I believe there was a rationale at some point for not using
cpal's timestamps. Does that still hold? If so, I think we should make an exception when theaudioworkletfeature is enabled. I can make a PR to provide this behavior.