WebKit Audio искажается на iOS 6 (iPhone 5) в первый раз после включения питания
Я боролся с неуловимой ошибкой искажения звука при использовании webkitAudioContext в HTML5 под iOS 6. Это может случиться в других обстоятельствах, но единственный способ получить 100% репродукцию - это при первом посещении моей страницы после отключения питания устройства. Похоже, что если вы посетите какую-либо аудио-страницу до посещения этой, проблема не возникнет.
Искажение происходит только с аудио, генерируемым webkitAudioContext.decodeAudioData() и затем воспроизводимым через webkitAudioContext.createBufferSource(). Воспроизведение аудио webkitAudioContext.createMediaElementSource() не будет искажать.
Я пропустил какой-то шаг инициализации? Вот код и HTML в полном объеме, которые я отправил в Apple в качестве сообщения об ошибке (но не получил ответа):
<!DOCTYPE html>
<html>
<head>
<script type="text/javascript">
var buffer = null;
var context = null;
var voice = null;
function load_music(file) {
context = new webkitAudioContext();
voice = context.createBufferSource();
var request = new XMLHttpRequest();
request.onload = function() {
context.decodeAudioData(request.response, function(result) {
buffer = result;
document.getElementById("start").value = "Start";
});
};
var base = window.location.pathname;
base = base.substring(0, base.lastIndexOf("/") + 1);
request.open("GET", base + file, true);
request.responseType = "arraybuffer";
request.send(null);
}
function start_music() {
if (!buffer) {
alert("Not ready yet");
return;
}
voice.buffer = buffer;
voice.connect(context.destination);
voice.noteOn(0);
document.getElementById("compare").style.display = "block";
}
</script>
</head>
<body onload="load_music('music.mp3')">
<p>This is a simple demo page to reproduce a <strong>webkitAudio</strong>
problem occurring in Safari on iOS 6.1.4. This is a stripped down demo
of a phenomenon discovered in our HTML5 game under development,
using different assets.</p>
<p><u>Steps to reproduce:</u></p>
<ol>
<li>Power cycle <strong>iPhone 5 with iOS 6.1.4</strong>.</li>
<li>Launch Safari immediately, and visit this page.</li>
<li>Wait for "Loading..." below to change to
"Start".</li>
<li>Tap "Start".</li>
</ol>
<p><u>Issue:</u></p>
<p>Audio will be excessively distorted and play at wrong pitch. If
another audio-enabled web site is visited before this one, or this
site is reloaded, the audio will fix. The distortion only happens on
the first visit after cold boot. <strong>To reproduce the bug, it is
critical to power cycle before testing.</strong></p>
<p>This bug has not been observed on any other iOS version (e.g. does
not occur on iPad Mini or iPod 5 using iOS 6.1.3).</p>
<input id="start" type="button" value="Loading..." onmousedown="start_music()" />
<span id="compare" style="display:none;"><p><a href="music.mp3">Direct link</a> to audio file, for
comparison.</p></span>
</body>
</html>
Примечание: основной текст предполагает, что это происходит только на iOS 6.1.4, но я хочу сказать, что проблема возникает только при включении питания в этой ситуации. Я столкнулся с проблемой на iPad Mini под 6.1.3 тоже, но не при включении питания.
Изменить: несколько вещей, которые я пытался... Откладывать создание источника буфера не имеет значения. Использование разных транскодеров для создания файла.mp3, который он воспроизводит, не имеет значения. Воспроизведение одноразовой тишины в качестве первого звука не имеет значения, поскольку искажение продолжается для каждого звука decodeAudioData до тех пор, пока страница не перезагрузится. Если источники createMediaElementSource и createBufferSource смешаны на одной и той же странице, будет искажаться только звук createBufferSource (с использованием decodeAudioData). Когда я проверяю request.response.byteLength в случае сбоя и в случае сбоя, они совпадают, предполагая, что XMLHttpRequest не возвращает неверные данные, хотя я думаю, что повреждение данных может повредить заголовок MP3 и отобразить файл не воспроизводится в любом случае.
Существует одно заметное различие между условием отказа и состоянием без отказа. Значение только для чтения context.sampleRate будет 48000 в состоянии отказа и 44100 в состоянии без отказа. (Тем не менее, состояние ошибки звучит ниже, чем состояние без сбоев.) Единственное, что мне приходит в голову, это хак, при котором я обновляю страницу с помощью JavaScript, если в браузере, который должен сообщать 44100, обнаруживается 48000, но это серьезный userAgent скрининг и не очень будущее, что заставляет меня нервничать.
3 ответа
У меня были подобные проблемы, даже на iOS 9.2.
Даже без <video> тег, воспроизведение искажается при первом воспроизведении аудио на странице после холодной загрузки. После перезагрузки работает нормально.
Начальный AudioContext кажется, что по умолчанию установлено значение 48 кГц, и именно здесь происходят искажения (даже при использовании звука с частотой дискретизации 48 кГц). Когда воспроизведение работает правильно, AudioContext имеет частоту дискретизации 44,1 кГц.
Я нашел обходной путь: можно воссоздать AudioContext после воспроизведения начального звука. Недавно созданный AudioContext похоже, имеет правильную частоту дискретизации. Сделать это:
// inside the click/touch handler
var playInitSound = function playInitSound() {
var source = context.createBufferSource();
source.buffer = context.createBuffer(1, 1, 48000);
source.connect(context.destination);
if (source.start) {
source.start(0);
} else {
source.noteOn(0);
}
};
playInit();
if (context.sampleRate === 48000) {
context = new AudioContext();
playInit();
}
Я нашел связанную ошибку с видео HTML5 и думаю, что я обнаружил корень проблемы.
Я заметил, что если вы воспроизводите видео с помощью <video> тег, он устанавливает значение context.sampleRate равным тому, в котором был закодирован звук видео. Кажется, что iOS Safari имеет один глобальный sampleRate, который он использует для всего. Чтобы увидеть это, попробуйте следующее:
// Play a video with audio encoded at 44100 Hz
video.play();
// This will console log 44100
var ctx = new webkitAudioContext();
console.log(ctx.sampleRate);
// Play a video with audio encoded at 48000 Hz
video2.play();
// This will console log 48000
var ctx = new webkitAudioContext();
console.log(ctx.sampleRate);
Эта глобальная частота выборки сохраняется при загрузке страниц и распределяется между вкладками и экземплярами браузера. Таким образом, воспроизведение видео на YouTube на другой вкладке может привести к поломке всего вашего декодированного звука.
Звук искажается, когда он декодируется с одной частотой дискретизации и воспроизводится с другой.
- Расшифруйте аудио и сохраните буфер
- Сделайте что-нибудь, чтобы изменить частоту дискретизации, например, воспроизведите видео или аудио файл
- Буфер воспроизведения (искаженный)
Я не знаю, почему это происходит после холодного старта. Если бы я догадался, это то, что Safari не инициализирует эту глобальную частоту дискретизации, пока вы не попытаетесь ее использовать.
Проблема все еще существует в iOS 7, поэтому я не думаю, что исправление будет в ближайшее время. Тем временем мы застряли на взломах, таких как проверка на измененную частоту дискретизации.
Пакет npm онлайн, чтобы исправить это:
https://github.com/Jam3/ios-safe-audio-context
npm install ios-safe-audio-context