iOS 9.2 creates audio issue

[TheDucc]

After the release of iOS 9.2 the web audio frame work has a bug on this platform related to the sample rate being set incorrectly when the buffer is created. For more information see this post:
http://www.html5gamedevs.com/topic/17326-ios-9-webaudio-issues/

The symptoms are audio playing to slow, or distorted because the sample rate is set to 48000 by default in iOS.

When you create the buffer you need to be able to set the default sample rate with creteBuffer. Something like this:

  var buffer = g_WebAudioContext.createBuffer(1, 1, 44100);
  var source = g_WebAudioContext.createBufferSource();
  source.buffer = buffer; 

So, could we talk about a patch too pass in the sample rate when you are creating the buffer in the options?

[TheDucc]

As part of my research (and a more eloquent explanation), this issues has a solution I have found here
https://github.com/Jam3/ios-safe-audio-context

It is the source of the sample code I provided above.

[nehz]

Thanks, I'll have a look at it

[TheDucc]

I also tried my hand at adding new code

I added a 'desiredSampleRate' to the options object in function WebAudio()

if (options.desiredSampleRate === undefined) options.desiredSampleRate = 44100;

And then tried to re-write the buffer, as in the example code
EDIT: I was forgetting to copy over the audio from the original buffer

    req.onload = function() {
      if (req.status !== 200 && audioBuffers[src]) return req.onerror();
      audioCtx.decodeAudioData(req.response, function(buffer) {
        if (desiredSampleRate != buffer.sampleRate) {
          var newBuffer = audioCtx.createBuffer(buffer.numberOfChannels, buffer.length, desiredSampleRate);
          var j = 0;
          var channelData = new Array(buffer.numberOfChannels);
          for (j = 0; j < buffer.numberOfChannels; ++j) {
            channelData[j] = buffer.getChannelData(j);
            newBuffer.copyToChannel(channelData[j], j, 0);
          }
          audioBuffers[src] = newBuffer;
        }else {
          audioBuffers[src] = buffer;
        }


        // Fire onBuffered event
        var handlers = eventHandlers[src].buffered;
        if (handlers) {
          // We can safely clean up all onBuffered event handlers, as once the
          // src media is cached, the onBuffered event can be fired immediately
          // for any new audio objects that are created henceforth
          eventHandlers[src].buffered = null;

          for (var i = 0; i < handlers.length; i++) {
            deferredApply(handlers[i]);
          }
        }
      });
    };

This gives much better results; but Sometimes the audio won't play.
But I am not 100% sure that the intermittent play issue is related yet.

[nehz]

Can't reproduce it on iOS 9.1, will update my device over the weekend to test this

[nehz]

Tried using test.mp3 -> 32k and 44.1k re-sampled using Audacity on iOS (9.2.1), which seems to work fine. Can you share the audio that's causing issues? And have you tried the latest iOS update ?

Also I just pushed an update which should help with iOS playing issues, give that a shot to see if it fixes the media not playing issue.

[chrisschaub]

Reviewing this code, line 124 throws a can't set read only property error:

self.audioSrc.onended = null;

[nehz]

Nice catch, thanks. e446e62 should fix it

[chrisschaub]

And now a new error:
Error: Failed to execute 'stop' on 'AudioBufferSourceNode': cannot call stop without calling start first.
at Error (native)
at WebAudio.stop (http://localhost:8100/lib/ngWebAudio/src/ngWebAudio.js:127:47)

I should add that this code was working flawlessly before the ios9.2 update mess. The code that calls stop in this case is unchanged from when ngWebAudio was working pre 9.2. It just does a stop of any playing audio file (and one is playing).

[nehz]

Thanks! Sigh... WebAudio API is just horrible to work with. Pushed a new commit that should address this new bug hopefully fca6b1f. Thanks for hanging in there!

[chrisschaub]

Thanks, error gone. The only issue I see now is that

onEnd

seems to get fired on "stop" as well as being at the end of the file. Thanks for your help, much appreciated!

[nehz]

That was the original intention of onEnd (e.g the event fires when ever the media "stops"; was a bug that prevent this, which I fixed along with other changes), however might refactor this into two events, onStop and onEnd? Let me know if you think it would be useful.

[chrisschaub]

I think both are valuable. Detecting a finish of play is a unique event in
many ways.

On Tuesday, February 2, 2016, Zhen Wang notifications@github.com wrote:

That was the original intention of onEnd (e.g the event fires when ever
the media "stops"; was a bug that prevent this, which I fixed along with
other changes), however might refactor this into two events, onStop and
onEnd? Let me know if you think it would be useful.

—
Reply to this email directly or view it on GitHub
#2 (comment).

Christopher Schaub
http://chris.schaub.com

[nehz]

I've pushed an update for it and created a separate issue to keep track of any regressions or unintuitive behaviours #7

[chrisschaub]

Thanks, seems much better. Testing.

[chrisschaub]

Ok, there is still a distortion bug on iOS 9.2. The issue is compounded by the fact that copyToChannel is not available on iOS right now, even with the webkit prefix. This gets at the issue:

https://github.com/Jam3/ios-safe-audio-context/blob/master/index.js