No sound on iOS 6 Web Audio API

Solution 1:

Edit (November 2015): iOS 9 no longer allows audio to start in a touchstart event, which breaks the solution below. However it works in a touchend event. The original answer for iOS 6 is left intact below, but for iOS 9 support make sure you use touchend.

Well, sorry to answer my own bounty question, but after hours of debugging I finally found the answer. Safari on iOS 6 effectively starts with the Web Audio API muted. It will not unmute until you attempt to play a sound in a user input event (create a buffer source, connect it to destination, and call noteOn()). After this, it unmutes and audio plays unrestricted and as it ought to. This is an undocumented aspect of how the Web Audio API works on iOS 6 (Apple's doc is here, hopefully they update it with a mention of this soon!)

The user can be touching the screen a lot, engaged in the game. But it will remain muted. You have to play inside a user input event like touchstart [edit: touchend for iOS 9+], once, then all audio unmutes. After that you can play audio at any time (doesn't have to be in a user input event).

Note this is different to the restrictions on HTML5 audio: typically you can only start audio at all in a user input event, and only play one sound at a time; the Web Audio API fully unmutes after the first play-in-user-input, so that you can play sounds at any time, and then you can mix them polyphonically, process cool effects, etc.

This means many games already on the web using the Web Audio API will never play audio, because they do not happen to issue a noteOn in a touch event. You have to adjust it to wait for the first user input event.

There are a few ways to work around this: don't play your title music until the user touches the screen; have an initial 'touch to enable audio' screen and play a sound then begin the game when they touch; etc. Hopefully this will help anyone else having the same problem save some time trying to debug it!

Solution 2:

You can try to debug it using the Web Inspector on Safari 6 on a mac.

1. Enable "Webkit Inspector" in Mobile Safari settings/advanced.
2. Connect device to a Mac running Safari 6 using a USB cable.
3. Load your page/game
4. Go to menu Develop->[devicename]->[pageurl]

It doesn't work out of the box for me, but with a few tries it can help narrow down the problem.

Apparently there is also the thing that audio can only be triggered by a user action. I'm not sure this is true 'cos some code that works on iOS6 on iPhone4 doesn't play any sound on an iPad (also iOS6).

Update: Some success with web audio on iPhone4+iOS6. Found that the "currentTime" remains stuck at 0 for a while as soon as you create a new audio context on iOS6. In order to get it moving, you first need to perform a dummy API call (like createGainNode() and discard the result). Sounds play only when currentTime starts to run, but scheduling sounds exactly at currentTime doesn't seem to work. They need to be a little bit into the future (ex: 10ms). You can use the following createAudioContext function to wait until the context is ready to make noise. User action doesn't seem to be required on iPhone, but no such success on iPad just yet.

function createAudioContext(callback, errback) {
    var ac = new webkitAudioContext();
    ac.createGainNode(); // .. and discard it. This gets 
                         // the clock running at some point.

    var count = 0;

    function wait() {
        if (ac.currentTime === 0) {
            // Not ready yet.
            ++count;
            if (count > 600) {
                errback('timeout');
            } else {
                setTimeout(wait, 100);
            }
        } else {
            // Ready. Pass on the valid audio context.
            callback(ac); 
        }
    }

    wait();
}

Subsequently, when playing a note, don't call .noteOn(ac.currentTime), but do .noteOn(ac.currentTime + 0.01) instead.

Please don't ask me why you have to do all that. That's just the way it is at the moment - i.e. crazy.

Solution 3:

I managed to figure out a simple solution which I'm sure must have been documented elsewhere - but sometimes we have to spend hours figuring these things out for ourselves...

So it seems many tutorials (such as this one on html5rocks) instruct you to do the following steps :

• Create an instance of window.AudioContext and if that doesn't exist (which it doesn't on iOS) then create window.webkitAudioContext.

• Create an XMLHttpRequest to load your sound file

• On the load event run context.decodeAudioData(....) and then createBufferSource(), filling it with the decoded data, and finally source.start(0) to play the sound.

As others have pointed out you must create the AudioContext (which incidentally you must store and use for the lifetime of the page) as a result of a user interaction (click or touchstart).

HOWEVER : For iOS to 'unlock' its audio capabilities you MUST have audio data available when you create the AudioContext. If you load the data asynchronously there's nothing for it to play. It is not sufficient to merely create the AudioContext inside a click event.

Here's two solutions for reliable iOS playback:

• 1) You must load at least one sound file before you even initialize the AudioContext, and then run all the above steps for that sound file immediately within a single user interaction (eg click).

• OR 2) Create a sound dynamically in memory and play it.

This is how I did that second option:

REMEMBER - MUST BE within click / touch event for iOS:

 window.AudioContext = window.AudioContext || window.webkitAudioContext;
 var context = new window.AudioContext();

 // you should null check window.AudioContext for old browsers to not blow up

 // create a dummy sound - and play it immediately in same 'thread'
 var oscillator = context.createOscillator();
 oscillator.frequency.value = 400;
 oscillator.connect(context.destination);
 oscillator.start(0);
 oscillator.stop(.5);    // you can set this to zero, but I left it here for testing.

 // audio context is now 'unlocked' and ready to load and play sounds asynchronously
 // YOU MUST STORE 'context' for future usage. DON'T recreate more AudioContexts

I imagine this is a common mistake - and I'm surprised after 3 years that nobody seems to have pointed this out or discovered it :-/