Sound pileup in chrome

Bugs
1

I am having touble with a sound pile-up problem having to do with the chrome web-browser.
I am starting and stopping several sounds in the game and they are apparently all in some “on-hold” state until the user presses the sound icon on the web-page.
The problem is, that the autostart events are all executed, but the mysound.stop(); do not seem to be waiting for execution but are simply ignored. As a result all the sounds start playing together, even though they should have already been stopped. There state also was “isPlaying” even though they were actually not playing due to the browser not allowing sound. Any ideas how to fix this.
Also the “BABYLON.Engine.audioEngine.masterGain.gain.value” variable always is one, even though the sound is not yet allowed in the browser.

2

cc @docEdub and if you can share a playground showing this problem, it will be of great use :slight_smile:

3

Sorry. Should have done this at the start. Here is an example which demonstrates the effect:

If your browser already allowed sounds to be played, this will sound quite normal. However, if it did not (e.g. pressing the “reload” symbol on Chrome), then both sounds start playing, as soon as you press the loadspeaker symbol in the top left corner.
The “music1.stop()” is simply ignored.

2 Likes
5

This is a bug. I’ll fix it.

3 Likes
6

Thanks for reporting this!

It was a little tricky to fix but PR 14047 should do it.

I left the isPlaying behavior the same because there’s a fair amount of existing code that relies on it being set to true whether the audio engine is locked or not. The PR will set isPlaying to false when stop is called before the audio engine is unlocked, now, though, so there’s some improvement there.

The BABYLON.Engine.audioEngine.masterGain.gain.value property is handled by the WebAudio API, so I left that as-is. If you want to see if the audio engine is locked or not, you can use the Engine.audioEngine.unlocked property.

Let me know if this works for you.

Cheers!

3 Likes
7

Thanks a lot for fixing this. I tried for a day to find a work-around but was not able. I remember also trying BABYLON.Engine.audioEngine.masterGain.gain.value and it was always 1.0 no matter whether the audio was locked or not. I don’t know if this is the proper behaviour.
Thanks for the hint to Engine.audioEngine.unlocked. This is useful. Since I do not know how to set up Babylonjs to work with your pull request, I probably wait till the next release to try.