Remove unmute button

Questions
21

Here is some information regarding browser autoplay policy.

Chrome’s autoplay policies are simple:

Media Engagement Index

The Media Engagement Index (MEI) measures an individual’s propensity to consume media on a site. Chrome’s approach is a ratio of visits to significant media playback events per origin:

  • Consumption of the media (audio/video) must be greater than seven seconds.
  • Audio must be present and unmuted.
  • The tab with the video is active.
  • Size of the video (in px) must be greater than 200x140.

From that, Chrome calculates a media engagement score, which is highest on sites where media is played on a regular basis. When it is high enough, media is allowed to autoplay on desktop only.

More info here - Autoplay policy in Chrome - Chrome Developers

3 Likes
22

There’s a reason it’s even a thing that it requires a user input :wink:

You have all the tools needed to not display the default unmute button and implement your own music.play() logic on user interaction :slight_smile:

23

I know that sound requires user interaction. Same in all browsers. I showed in my above link how to enable it after interaction.

I’m just saying that Babylon keeping things muted even after user interaction is the wrong thing for Babylon to do. Most people don’t want that. Most people want their audio to play as soon as interaction happens (without requiring the end user to also press an un-mute button).

I just joined a Babylon project, and the default audio behavior was bugging everyone on the team. Not a single person thought having the app muted (even after user interaction) was a good default.

That’s all I’m trying to say. :smiley:

24

@trusktr
Please stop necro’ing multiple threads on the same topic :pray:

Due to the backwards compatibility promise of BabylonJs,

It’s unlikely that the default behavior will be changed, there are already tons of projects expecting it to behave as it currently does, all of which should be able to upgrade to a newer version of BabylonJs seamlessly. Changing the default behavior would not allow this.

However, I decided to made you an example of how to properly handle this situation here:

I will add it to the docs aswell.

Please confirm if it works in safari, it’s dangerous to assume things when it comes to apple tech :slight_smile:

Edit
Listening to onAudioUnlockedObservable was unnecessary. updated pg.

1 Like
25

That one works, but this one doesn’t work in any browser desktop or mobile:

No sound with OnPickTrigger | Babylon.js Playground (babylonjs.com)

It is supposed to enable the music only when clicking one of the two boxes.

26

So the problem is that it requires one full user interaction to unlock the audio after the website is initially loaded, this can cause some issues when/if the first click is also wanting to play audio.

That PG works for me though when i click the right box with the actionManager attached, only because that click unlocks the audio and the audio is autoplay: true

Also keep in mind that audio unlocking is asynchronous.

Can you describe exactly what you hope to achieve?, preferably a PG with comments.
Is it continuous looping background music or a short audio clip that plays when clicking a mesh, etc

27

OnPickTrigger happens after the user clicked on the scene right? If so, then Babylon can ensure the logic runs after native click internally.

  • load website, and the scene is visible right away without interaction
  • user clicks something (OnPickTrigger on a mesh) and sound starts to play
28

Ok, took a few minutes to figure out.
BABYLON.Engine.audioEngine.unlocked property seems a bit unstable, causing some issues.

Please try this one

And with multiple sounds

2 Likes
29

From all of the threads made I am a bit at a loss as to whether or not the solution was found. I do hope it was :slight_smile:

And if there is something wrong, let’s keep the discussion to one thread explaining the issue.

Thanks @aWeirdo !

30

@RaananW I think it was solved :smile:

I did discover an issue when trying to use BABYLON.Engine.audioEngine.unlocked
Any idea why it is true by default?

Sometimes it will return true when reading it for the first time, even though the audio is not unlocked, I experienced the entire audioEngine siezing up a couple times and stop responding.

Do you think we can invert the behavior, set it to false by default and update to true if the browser does not require audio to be unlocked?

Context: “siezing up”.
No audio with autoplay.
We only want to call the unlock() function once.

2 Likes
31

yep, this would be considered a bug. Let me tag @docEdub - can you check this when you have the time?

32

Ya, I’ll take a look

1 Like
33

If we change the AudioEngine.unlocked flag to be initialized to false instead of true, it makes the mute button show up immediately whether a sound tries to play or not. Currently the mute button doesn’t show until a sound tries to play.

1 Like
34

To complicate things, I’ve discovered that this,

audioEngine.setGlobalVolume(0);
console.log(audioEngine.getGlobalVolume())

reports -1 if executed before any Sound has been created.

This implies AudioEngine state is coupled to Web Audio. Instead, AudioEngine should be an abstraction that is 100% a level above Web Audio, and should map its state to Web Audio once Web Audio is loaded, otherwise this internal behavior is leaking to the outside in a way that makes user code difficult to create, and buggy.

When a setter is given a value, the getter should always return the last value that was set.

1 Like
35

This should be fixed by PR 14177.

Thanks for reporting it!

4 Likes