Зміст
API веб-аудіо є потужним і може використовуватися для обробки та аналізу звуку в режимі реального часу, але це може зробити його складним у роботі. Використовуючи графік маршрутизації для передачі звуку від вузла до вузла, він відрізняється від інших веб-інтерфейсів API, і це трохи лякає, коли перший раз наближається до специфікації. У цьому творі ми розглянемо приклад маніпулювання аудіо в режимі реального часу, а потім візуалізуємо аудіодані.
Підключи і грай
Уявіть, що ви гітарист вашої улюбленої групи: звук надходить із вашої гітари, за допомогою педалей ефектів (ви хочете звучати важко, правда?) Та у підсилювач, щоб його можна було почути. API веб-аудіо працює аналогічно: дані надходять із вихідного вузла, через вузли перетворення і, зрештою, із звукової карти комп’ютера.
Все у веб-аудіо починається з створення екземпляра AudioContext інстанції. AudioContext можна сприймати як наше звукове середовище, і з контексту ми створюємо всі наші аудіовузли. Через це всі звукові вузли живуть усередині AudioContext, яка стає мережею підключених вузлів.
Спочатку нам знадобиться вихідний вузол, звідки походить аудіо. Існує кілька типів вихідних вузлів, таких як MediaElementAudioSourceNode для використання аудіо> елемент, a MediaStreamAudioSourceNode для використання вхідного мікрофона в реальному часі з WebRTC, Вузол генератора для квадратних і трикутних хвиль, або аудіофайл із символом AudioBufferSourceNode. У цьому випадку ми будемо використовувати MediaElementAudioSourceNode для використання власного контролю аудіо> елемент дає нам.
Тут ми будемо готові до префіксних назв об’єктів та будемо підтримувати різні аудіокодеки. Можливо, вам доведеться обслуговувати цю сторінку із сервера, щоб було встановлено відповідні заголовки для аудіофайлів. Давайте створимо аудіо> елемент, створити екземпляр AudioContext і гачок a MediaElementAudioSourceNode до нашого аудіо> елемент:
body> audio id = "audio-element" controls = "controls"> source src = "audio / augment.mp3" type = "audio / mpeg;"> source src = "audio / augment.ogg" type = "audio / ogg; codecs = vorbis; "> / audio> script> var ctx = new (window.AudioContext || window. webkitAudioContext) (); var audioEl = document.getElementById ("аудіо-елемент"); var elSource = ctx.createMediaElementSource (audioEl); / script> / body>
аудіо> звук елемента вбудовується в наш веб-аудіоконтекст. То чому ми не можемо почути трек, коли натискаємо кнопку відтворення? Оскільки ми перенаправляємо аудіо з елемента в наш контекст, нам потрібно підключити наше джерело до пункту призначення контексту. Наче ми граємо на електрогітарі, яка не підключена до підсилювача.
Кожен AudioContext екземпляр має a пункт призначення властивість: спеціальний звуковий вузол, що представляє звуковий вихід комп'ютера, і всі наші аудіовузли мають підключити метод, що дозволяє передавати аудіодані з одного на інший. Давайте підключимо наш вузол звукового елемента до вузла призначення, як гітарний кабель до підсилювача.
elSource.connect (ctx.destination);
Тепер, коли ми натискаємо на відтворення, у нас є аудіо> вузол елемента перекачується у вузол призначення і може почути пісню. Але це нічим не відрізняється від використання аудіо> тег самостійно. Давайте додамо вузол фільтра для відтворення з частотами звукової доріжки. По-перше, ми будемо керувати фільтром за допомогою повзунка та дисплея, щоб ми могли побачити, яке значення:
input id = "slider" type = "range" min = "100" max = "22000" value = "100" /> div id = "freq-display"> 100 / div>
Тепер ми повинні створити BiquadFilterNode: наш фільтр та функції, як еквалайзер у веб-аудіо. Як і у всіх вузлах, які ми створюємо, ми створюємо екземпляр нашого фільтра з AudioContext. Раніше ми підключали наш MediaElementAudioSourceNode безпосередньо до нашого контексту пункт призначення. Тепер ми хочемо, щоб наш вихідний вузол спочатку підключився до нашого фільтра, а наш фільтр - до пункту призначення, щоб наш вузол фільтра маніпулював аудіо, що передається через нього. Зараз у нас повинно бути щось подібне:
var ctx = new (window.AudioContext || window.webkitAudioContext) (); var audioEl = document.getElementById ("аудіо-елемент"); var elSource = ctx.createMediaElementSource (audioEl); var filter = ctx.createBiquadFilter (); filter.type = "низький прохід"; filter.frequency.value = 100; elSource.connect (фільтр); filter.connect (ctx.destination);
Вузли фільтрів мають кілька видів частотної фільтрації, але ми використовуватимемо за замовчуванням "низький прохід"- лише частоти нижче, ніж частота може пройти наскрізь. Послухайте: зверніть увагу, як це звучить так, ніби там поруч вечірка. До пункту призначення прямують лише частоти нижче 100 Гц, тому ми чуємо лише бас. Давайте підключимо наш повзунок, щоб ми могли маніпулювати цим фільтром.
var slider = document.getElementById ("повзунок"); var freqDisplay = document.getElementById ("freq-display"); // Обробник подій між браузерами if (slider.addEventListener) {slider.addEventListener ("change", onChange); } else {slider.attachEvent ("onchange", onChange); } функція onChange () {// Оновіть значення частоти вузла фільтра значенням повзунка filter.frequency.value = slider.value; freqDisplay.innerHTML = slider.value; }
За допомогою нашого повзунка, який здатний контролювати частоту нашого вузла фільтра, ми можемо керувати відтворенням звуку в режимі реального часу. Щоб краще розглянути дані, що передаються, ми можемо візуалізувати дані про частоту сигналу. Хоча наш вузол фільтра фактично модифікував звук, що виходить із наших динаміків, ми використовуватимемо два нових вузли для аналізу сигналу, а не впливу на нього. Давайте створимо AnalyserNode і a ScriptProcessorNode:
аналізатор var = ctx.createAnalyser (); var proc = ctx.createScriptProcessor (1024, 1, 1);
createScriptProcessor (раніше createJavaScriptNode) метод приймає три аргументи. Перший - це розмір буфера, який повинен мати ступінь 2, а кількість входів і виходів - це решта аргументів відповідно. За допомогою вузла процесора ми можемо запланувати випуск події, коли обробляється достатньо звуку. Якщо розмір нашого буфера становить 1024, це означає, що кожного разу, коли обробляється 1024 вибірки, наша подія запускатиметься.
Наші AudioContext частота дискретизації становить 44100 Гц (44100 семплів обробляється в секунду), і наша подія запускатиметься кожні 1024 семпли - кожні 0,023 секунди або 43 рази в секунду. Зберігаючи це просто, наш процесорний вузол дозволяє нам підключатися до зворотного виклику, коли обробляються нові аудіодані. Скористаємось цим, щоб невдовзі намалювати на полотні.
Використовуючи наш процесор скриптів як гачок зворотного виклику, нам потрібен наш AnalyserNode щоб отримати дані. Але наш аудіосигнал повинен проходити як через аналізатор, так і через процесор: давайте змінимо нашу маршрутизацію та надішлемо вихід нашого відфільтрованого сигналу в аналізатор, тоді аналізатор підключиться до нашого призначення звуку та процесора сценарію:
elSource.connect (фільтр); filter.connect (аналізатор); analyser.connect (proc); filter.connect (ctx.destination); proc.connect (ctx.destination);
Помилка WebKit означає, що ми повинні підключити вихід процесора назад до місця призначення, щоб отримувати події обробки звуку, які ми використаємо за мить.
Частотний контроль
Тепер наша аудіомаршрутизація налаштована, давайте підключимось до тієї події обробки, про яку я згадав раніше. Ми можемо призначити функцію a ScriptProcessorNode's onaudioprocess властивість викликати, коли наш буфер заповнений обробленими зразками, і використовувати наш AnalyserNodeЗдатність отримувати вихідні дані про частоту сигналу.
Аналізатора getByteFrequencyData заповнює Uint8Array зі звуковими даними поточного буфера, в даному випадку як значення від 0 до 255. Ми використовуємо один і той же масив під час кожного виклику, тому нам не потрібно продовжувати створювати нові масиви.
// Зробити Uint8Array таким самим розміром, що і дані var count count bin аналізатора = new Uint8Array (analyser.frequencyBinCount); proc.onaudioprocess = onProcess; функція onProcess () {analyser.getByteFrequencyData (дані); console.log (дані [10]); }
На даний момент ми просто роздруковуємо десятий елемент аудіоданих для кожного процесу (не дуже цікаво), але ми можемо бачити, як запускається наша подія процесора за допомогою нашого аналізатора, який інтерпретує дані, що передаються через нього. Це було б набагато цікавіше намалювати на полотні. Додайте a полотно> елемент із символом ідентифікатор з "полотно", ширина 1024 і висота 256 - давайте подивимось на код креслення, який ми додамо до нашого в процесі функція.
var canvas = document.getElementById (‘canvas’); var canvasCtx = canvas.getContext (‘2d’); функція onProcess () {analyser.getByteFrequencyData (дані); canvasCtx.clearRect (0, 0, canvas.width, canvas.height); for (var i = 0, l = data.length; i l; i ++) {canvasCtx.fillRect (i, - (canvas.height / 255) * дані [i], 1, canvas.height); }}
Тепер подія викликається щоразу, коли звуковий буфер обробляється, завдяки нашому процесорному вузлу, оскільки наш вузол аналізатора заповнює Uint8Array з аудіоданими, і ми очищаємо полотно та надаємо йому нові дані у вигляді частотних бункерів, кожен із яких представляє діапазон частот. Проводячи очищення елементів керування фільтром вперед і назад, ми бачимо на полотні, що знімаємо високі частоти, коли рухаємо повзунок вліво.
Ми бачимо, що, підключивши звукові вузли, ми можемо маніпулювати звуками, які чуємо, і візуалізувати аудіодані. У цьому прикладі використовується простий вузол фільтрування біквадрів, але є суперечки, посилення, затримки та інші способи зміни аудіоданих для музикантів, розробників ігор та любителів синтезаторів. Проявіть творчі здібності та грайте за допомогою Web Audio API, оскільки між аудіоінженерами та веб-розробниками рядки стираються.
Слова: Джордан Сантелл
Ця стаття спочатку з’явилася у випуску 254 журналу net.
