On mobile devices that support HTML5 - IOS specifically, an <audio> tag element must exist to actually play a song loaded from a server to prevent "Failed to execute 'play' on 'HTMLMediaElement': API can only be initiated by a user gesture."

[mhdSid]

Mobile browsers have always had a problem when it comes to playing audio files in the browser.

Both Chrome & Safari state that a user interaction event - click event - must occur for an audio file to be in the playing state.

Any HTTP request should occur in the same 'stack frame' of the click event.

When using Chrome on Android, we tried to request a URL from the server, to give it to SoundManager that creates an tag dynamically and feed its source with the given URL. The song didn't play.

We found a solution to this problem that is to play a blank mp3 file locally, get the song URL from the server, then replace the currently playing song with the new URL.

Plus, the tag must not be created dynamically.

[DvirSh]

Hi, Iv'e tried using the code you wrote here inside my react application (AKA creating the audio element as soon as the application loads and before I play the first sound).
It didn't work for me - the error message no longer appears but I still cannot hear the sounds until I'm interacting with the view.
Anything I might be missing?

[mhdSid]

On top of updating SM2 to help prevent this issue, we played a blank.mp3 file and once we want to play the actual desired song, we pause, switch the blank.mp3 sound's URL with the new desired URL, and play again.

[mhdSid]

Hope this help your issue. Cheers!

[DvirSh]

Unfortunately it does not work for me. I'm trying to use the native Audio javascript component, such as:

sound = new Audio(emptySoundUrl);
sound.play();
setTimeout(() => {
    sound.pause();
    sound.src = realUrl;
    sound.play();
}, 3000);

But it still prompts the error message that the user must initiate the operation with a gesture...
Any suggestion?

(BTW it seems there's nobody to accept the PR :) )

[mhdSid]

You shouldn't use it as such, but you should initialise soundManager and it creates an HTMLAudioElement manually and place it in the DOM.

[scottschiller]

Sorry for the late follow-up on this, I'm curious about this PR but hesitant to simply merge it - something doesn't sound quite right about the user experience.

It sounds like you are saying the user needs to tap / click / act twice to get audio to start, which is undesirable. However, SM2 only requires one click/tap to start audio.

You can create and play a sound from a single user action in SM2, but it must be synchronous - no setTimeout(), etc., allowed between the user action and the SM2 createSound() / play() calls.

It seems you're suggesting that if an <audio> element exists in the DOM, then audio playback can start with a single tap/click, or possibly no user interaction.

My experience is that on mobile, user action is always required for playback to start - and on iOS, there is no difference whether the Audio() element is in JS, or attached as a live element in the DOM - so this PR will not change that.

[mhdSid]

Dear Scott, Unfortunately, after going in depth in the SoundManager2 api by using it in our Web App on https://play.anghami.com, we found that there's a limitation to play audio on mobile, due to the error 'Call to play must happen from a user gesture event'. We use a single page app framework AngularJs, and we initiate the player through a directive that is a custom element to manipulate that element and add logic to it. Let's take this scenario where I click on a track from a list. The click method handles loading the track hash from the server and building the URL on the client, and issuing a click event to play the track by using soundManager.createSound method. In fact, this didn't work, on both Android and IOS devices. Googled around for some solutions and one have stated that if you try to play a blank sound, wait for the url to load asynchronously, then switch the src with the new URL, it would work. However, the warning in the console persisted. This PR is a solution for this problem that has been tested to work on mobile devices. On top of that, if there's a request to the server, the developer should call play with an empty URL so he can get over the browser limitation, and once the full URL is built, he switches the src with the new URL and play without any other problem. I truly believe that this is the solution, if there was test cases, we would have run them and issued an asynchronous to play a song, we would have faced the same solution.

[mhdSid]

It's a perfect solution for this. Few days ago, at Google IO, they talked about the state of HTML Audio and about those concerns. A member of our team went and he discussed with us the changes that are going to happen and one of them is Autoplay on mobile and other concerns such as the above.

…

On Sun, May 21, 2017 at 7:02 PM, Mohammad Sidani ***@***.***> wrote: Dear Scott, Unfortunately, after going in depth in the SoundManager2 api by using it in our Web App on https://play.anghami.com, we found that there's a limitation to play audio on mobile, due to the error 'Call to play must happen from a user gesture event'. We use a single page app framework AngularJs, and we initiate the player through a directive that is a custom element to manipulate that element and add logic to it. Let's take this scenario where I click on a track from a list. The click method handles loading the track hash from the server and building the URL on the client, and issuing a click event to play the track by using soundManager.createSound method. In fact, this didn't work, on both Android and IOS devices. Googled around for some solutions and one have stated that if you try to play a blank sound, wait for the url to load asynchronously, then switch the src with the new URL, it would work. However, the warning in the console persisted. This PR is a solution for this problem that has been tested to work on mobile devices. On top of that, if there's a request to the server, the developer should call play with an empty URL so he can get over the browser limitation, and once the full URL is built, he switches the src with the new URL and play without any other problem. I truly believe that this is the solution, if there was test cases, we would have run them and issued an asynchronous to play a song, we would have faced the same solution.

-- *Mohammad K. Sidani* Developer - Mobile, Web, Entertainment B.S Computer Science *E-mail:* [email protected] *Tel:* +96176834807 Beirut, Lebanon - Raas El Nabeh - Mohammad El hout St. - El Kibbi Bldg. - G.F <https://github.com/mhdSid> <https://lb.linkedin.com/in/mohammad-sidani-6b9a32aa>

[mhdSid]

@Lazey5 Check this out:
It adapts to any device. Takes care of all the matters that you & I have faced.
After dwelling in all web audio matters, I've spent two months writing this.
https://www.npmjs.com/package/anghami-audio-manager

[mhdSid]

@scottschiller
Dear Scott,

At Anghami, we heavily use SoundManager2 in order to give a pleasant music experience on the web. However, on some browsers such as Instagram browser, iOS, android, PS4, we have faced a lot of issues with SoundManager2 in order to fetch songs from the server and play.
As a perfect solution for this, we have decided to drop SoundManager2 on these browsers except for web, and create our own AudioManager

Please I would like you to check it out and give me a feedback.

[scottschiller]

Thanks for the update, sorry for the random spam comments above - reported.

I still haven't worked this PR in, as you should be able to initiate a play() request directly from a user action like a click or touch with SM2 as-is. I realize this doesn't cover your particular case, I will need to address that.

If you're trying to work around asynchonous fetches to get the MP3 (for example) you want to play and that's why you must play a blank .mp3 first, my $.02 is that you're playing with fire in hoping that - for example, playing a silent sound and then having it onfinish() and go to the next URL when it's known - will work, but sounds pretty risky.

Notwithstanding, you've indicated you found a solution and SM2 should also handle this - your point about the Audio() / <audio> (?) being created on the fly, i.e., at the time of click, might be the distinction for the issue you're describing. That's interesting.

SM2 has existed for over 10 years now - not to say that means it's good by default, but it has gone through a lot of testing and has dealt with obscure browser bugs along the way.

Mobile is picking up the pace, and desktop is starting to adapt mobile's auto-play blocking as well. I have intent to move SM2 to 100% HTML5 soon, though it won't matter much with regards to retiring of Flash or Chrome's stated deadline for the new auto-play restrictions. Ideally, developers aren't running afoul of those rules unless there's a very specific exception like in your async case.