decodeAudioData example does not work on Safari
bwl21 opened this issue · 24 comments
-> https://mdn.github.io/webaudio-examples/decode-audio-data/
does not work on safari (Version 11.0.2 (11604.4.7.1.6) on OSX 10.11.6)
Steps to reproduce
- open https://mdn.github.io/webaudio-examples/decode-audio-data/ on safari
- push "play" button
- nothing happens
- open debugger (ALT-CMD-I)
- you see the point of failure
request.onload = function() {
var audioData = request.response;
audioCtx.decodeAudioData(audioData, function(buffer) {
myBuffer = buffer;
songLength = buffer.duration;
source.buffer = myBuffer;
source.playbackRate.value = playbackControl.value;
source.connect(audioCtx.destination);
//source.loop = true;
loopstartControl.setAttribute('max', Math.floor(songLength));
loopendControl.setAttribute('max', Math.floor(songLength));
},
function(e){"Error with decoding audio data" + e.err}); //<-- null is not an object
}
In fact the error callback gets a null parameter.
Hrm. I tried changing the parameter to error, which is what it says it is in the spec. But it still doesn't work. This looks like a Safari bug to me - it works fine in other browsers.
Also, the loop start and end times will not function as expected unless you un-remark the line:
source.loop = true;
which is currently remarked out.
@jakelewis3d this is a good point; I've fixed that.
@jakelewis3d does it work on safari with source.loop = true? if Yes, does it mean that percussion sounds cannot be used in safari?
Ogg format is not supported by safari.
Does someone fancy updating the example to offer an MP3 format file too? I will get to it eventually, but I'm crushingly busy right now.
@chrisdavidmills See attached .zip viper.mp3.zip.
@guest271314 thanks for the valient effort at fixing this, but ... it still doesn't seem to work for me. I also tried moving the audio context creation inside a user gesture, and rewriting the forking code that chooses between AudioContext and webkitAudioContext...
...Safari no longer errors. It now just fails silently
¯_(ツ)_/¯
@chrisdavidmills Do not currently have access to Safari, cannot verify the output. The closest that am able to test the code is Epiphany 3.28.5 where .ogg is decoded (brion/ogv.js#533 (comment)). Reading the code again, source.start(0) should probably be within decodeAudioData() callback within getData()?
Safari does fail or report missing coverage for several Web Audio API methods at https://wpt.fyi/interop/webaudio/the-audio-api/the-audiobuffersourcenode-interface/audiobuffersource-multi-channels.html?label=master&label=experimental&aligned from https://github.com/web-platform-tests/wpt/blob/07d9f452d740d98ded5b11c176ba783fe9d80e5b/webaudio/the-audio-api/the-audiobuffersourcenode-interface/audiobuffersource-multi-channels.html.
As it is marked as fixed, I tried with the steps above. But it does not work either on Safari 13.9.4
Have you filed a Safari bug? Have you tried https://github.com/jfrancos/oggdec-wasm as workaround?
It's 2,5 years later as this problem was reported, and it still does not work on Safari! At least you should make a note in the code that the example is not compatible with Safari.
It's 2,5 years later as this problem was reported, and it still does not work on Safari! At least you should make a note in the code that the example is not compatible with Safari.
I've added a note to the page. I've tried to debug this a few times now, and never gotten anywhere, which is really frustrating. I just don't have the time to have a proper look at it.
So I have been researching a bit with the keywords "Web Audio Api Loop Demo" and found actually quite a few examples. Most of them do not work on Safari either (they do not include webkit), BUT there is this one where even 3 loops are going at the same time: https://forestmist.org/share/web-audio-api-demo
Unfortunately, that code is too complex for me to understand, but you might find there the necessary inspiration to improve your solution which is the simple task of looping that most users like me need.
So we know now, that looping and buffering sounds also works in Safari. Maybe the problem lies in the way you load the audio file?
Here are some more working examples and a great article about what has to be done to make the Web Audio API work in Safari: https://jakearchibald.com/2016/sounds-fun/
Another script that just does looping (without selectable start or end looping points) is at https://github.com/veltman/loopify. It works on Safari and other browsers without a glitch and is just a few lines of code, so it should be easy for a pro programmer to find the bug in the decodeAudioData example.
After playing around with the Web Audio API for a week, I noticed the following policy in Safari: It always wants a user gesture right before you start playback. You can not invoke downloading and playing an audio file at the same time from one button click!
So if you change your code FROM:
play.onclick = function() {
getData();
source.play(0);
TO:
getData();
play.onclick = function() {
source.play(0);
Safari will start playback as intended. Unfortunately though, it will throw an error when you hit the play button a 2nd time. Chrome's console says: "Failed to execute 'start' on 'AudioBufferSourceNode': cannot call start more than once."
@thosch6 thanks for that hint. I am still dealing with this problem more than a year later. Did you find out more since then?
In a simple test I could confirm that getting the data using fetch in the same method as decodeAudioData does not work. But how far exactly do these steps have to be separated and what exactly is it about getting the data? Getting the cached file from an indexed DB did not seem to work either
Thanks for the tip.
In case this is helpful anyone else in the future: The solution for me was to actually do both the loading and decoding in one function but playing the sound in another function triggered by a separate event.
let audioBuffer;
async function init() {
const audioFile = await fetchSoundArrayBuffer();
audioBuffer = await this.audioContext.decodeAudioData(audioFile);
}
function play() {
const source = this.audioContext.createBufferSource();
source.buffer = audioBuffer;
source.connect(this.audioContext.destination);
source.start();
}I had similar problem lately that decodeAudioData failing without much information. After trying lot of things realized,
the fix was actually using .m4a audio files for iOS safari browsers.
But keep in mind, Firefox and some other Non-Apple platforms won't work with m4a.
So we first do check to detect iOS safari browser and use m4a version else use the mp3 everywhere.
@shreyas-jadhav Does iOS support MP3?
according to my tests on our app, iOS 14 fails all the time to decodeAudioData with .mp3, while iOS 15 was failing 1/5 times roughly, else it was just working. i know this doesn't sound reasonable as a programmer. but it just worked for us when we switched to .m4a
Web Audio API specification https://webaudio.github.io/web-audio-api/#dom-baseaudiocontext-decodeaudiodata
Audio file data can be in any of the formats supported by the audio element.
Does Safari play MP3 files at HTML <audio> element?
Yes it does support mp3 for audio element and even for decodeAudioData.
Actually there might be different reason why it wasn't working for us with mp3.
We had 6 mp3 files each of 10-20 MB. And the crashing happened because we decoded all the files simultaneously. (maybe because some memory issues idk) just now realized conversion to m4a has reduced the size of mp3 files and maybe thats why it isn't happening now.
Seems that only iOS safari goes out of memory or something while decoding simultaneously.
sorry for posting unrelated & vague solution before.