For this format you need to add this in the options (it seems to me)
skipCodecCheck: true
new BABYLON.Sound("sound", "Url", scene, null, {
loop: true,
autoplay: true,
spatialSound: true,
skipCodecCheck: true
});
Yes! Youâre right!
I was too lazy to make playground, but your advice is working for me, I love this community 
@sebavan I think it should be noticed in the documentation. For example, in this part Audio | Babylon.js Documentation
Will be done with Update playingSoundsMusic.md by sebavan ¡ Pull Request #855 ¡ BabylonJS/Documentation ¡ GitHub
Thatâs not the problem. Babylon should simply enable sound inside a user interaction by default, rather than showing an unmute button and requiring users to press it. (Imagine if every game you ever played always started muted by default, thatâs not the experience users expect).
The solution so you can get rid of the unmute button once and for all is simple in userland (though Babylon should just do it by default!):
// make your scene, as usual:
const engine = new BABYLON.Engine(canvas, true);
const scene = new BABYLON.Scene(engine);
// create any auto-playing sounds here (f.e. music)
const autoplayingSound = new BABYLON.Sound()
// But *BEFORE* you do anything else, add this:
document.body.addEventListener('pointerdown', () => {
// THIS! This has to run *before* you call .play() on ANY sound.
// This unlocks all sounds, and the unmute button will not appear. Yay!
BABYLON.Engine.audioEngine?.unlock()
// start auto-playing sounds
autoplayingSound.play()
}, { once: true });
// Continue as before, add your scene.onPointerWhatever handlers, play sounds in those handlers, etc.
scene.onPointerUp = () => {
someClickSound.play()
}
Babylon should just do this by default, and it can additionally provide the button to mute/unmute (rather than just unmute). It would make a lot of sense to users that way.
Aaaaaaand, that doesnât work in iOS Safari. Go figure. Calling .unlock() in the appâs very first pointerdown handler, in iOS Safari, doesnât prevent the unmute button from appearing and pressing the unmute button doesnât do anything. Totally borked.
Simple suggestion. It appears you are experiencing a number of issues with the audio in your current project. Iâm afraid replying to old (pseudo)-solved topics might not be the most efficient. May be you could open a new topic and list all of your problems and findings. I believe @RaananW is the person you want to have on-board to get the answers/solutions you are seeking.
cc @docEdub to verify the unmute on IOS.
About the unmute button on itself, it is rather a UX choice if you think about how many video player autoplays muted first.
We provide a default embedded approach as an helper only. You can totally disable the behavior and implement your own if you favor another experience.
I have a fix incoming for the mute button getting stuck, but your example will still make the mute button show up on iOS because iOS Safari doesnât allow the audio to be unlocked from a pointerdown event. It will only unlock the audio from a click event.
When the mute button fix is merged, changing the following from âŚ
document.body.addEventListener('pointerdown', () => { ...
to
document.body.addEventListener('click', () => { ...
should get it working like you want on all platforms and browsers.
Hereâs another example of the mute button getting stuck in the wild,
and hereâs the fix:
Fixed issue #174 by GeneUNCG ¡ Pull Request #175 ¡ aws-samples/amazon-sumerian-hosts (github.com)
The fix does not seem to have to do anything with user interaction timing (or maybe it does indirectly), so it may be worth looking into why that particular change causes Babylonâs audio to not get stuck.
Any any case, the best UX would be that when you interact with any part of the Babylon scene, not just the unmute button, the audio will start working. Then people wonât need to work around the unmute button (and you can even disable it by default, or just delete it entirely).
The mute button getting stuck on iOS is fixed as of Babylon.js version 6.17.1.