search

chrisguttandin / standardized-audio-context

A cross-browser wrapper for the Web Audio API which aims to closely follow the standard.
MIT License
680 stars 33 forks source link

ConvolverNode reverb tail intermittent misbehavior #970

Closed marcelblum closed 3 years ago

marcelblum commented 3 years ago

While experimenting with rapid fire starting and stopping playback of samples through convolver nodes I noticed that sometimes the reverb tail is not audible/gets cut off too soon. Also sometimes it sounds like the tail resumes from where it got cut off the next time output is fed through the same convolver node. I'm guessing maybe this has something to do with the way the fix for #961 was implemented. Observed on Windows Chrome & FF and unable to repro with a native web audio context on the same platforms.

Test case: https://codepen.io/keymapper/pen/BaLPreB

For me I can repro if I click to start and stop the audio a few times in a row in rapid succession (for example stopping the audio before the track's first snare hit each time). If I start/stop 5 times the issue almost always occurs at least once.

Same code without standardized-audio-context, does not repro here for me: https://codepen.io/keymapper/pen/LYRabWO

And just for reference here's an implementation with Tone.js that also exhibits the same issue: https://codepen.io/keymapper/pen/oNzMKNM

chrisguttandin commented 3 years ago

Hi Marcel, thanks a lot for reporting this and for providing a test case.

I think the problem is fixed. However it was a very hard to reproduce race condition. Could you please double check with the latest version (v25.1.9) and let me know if it works for you now?

marcelblum commented 3 years ago

Awesome, thank you, seems fixed AFAICT! I have a more complex scenario using Tone.js where it was a lot easier to trigger this bug which involved realtime drum pad use with different drum sounds fed through different convolver nodes, and I'll know for sure that this was fixed when this new standardized-audio-context version is bundled into the next Tone version and I can do a more thorough test.

BTW is there any way to programmatically query which standardized-audio-context version is currently in use? I didn't see any "version" property available in the standardized-audio-context exported object.

chrisguttandin commented 3 years ago

Mmm no there isn't a programmatic way. Well unless you would read it from the package.json file or something like that.

Thanks for keeping an eye on this. Feel free to re-open the issue if it isn't fully fixed.