Чому звук у бездротових навушниках відстає від картинки?

Ви дивитеся ролик у телефоні, у вухах — бездротові навушники, і губи на екрані ворушаться раніше, ніж чути слова. Знімаєте навушники, вмикаєте динамік — розсинхрон зникає. У грі те саме, тільки помітніше: постріл видно, звук приходить услід, і поправку доводиться тримати в голові. А в меню телевізора живе повзунок «затримка звуку», і хтось же його туди поставив.

Здогадка, яка напрошується першою, — що винен слабкий сигнал або стара версія Bluetooth і що новіші навушники з новішим кодеком це вилікують. Друга здогадка м'якша: затримка є, але вона стала, тому її досить один раз виміряти й компенсувати. Обидві спираються на те, що десь у стандарті записано, скільки саме мілісекунд. Не записано.

Профіль називає ланки й не називає суму

Advanced Audio Distribution Profile — це той профіль, яким їде стереозвук на навушники; чинна редакція v1.4.1 датована 30 червня 2025 року. Bluetooth SIG перелічує в розділі 2.3, звідки затримка береться: обробка радіосигналу, буферизація даних, кодування й декодування потоку. І тут же віддає боротьбу з нею на розсуд реалізації. Числа немає ніде в документі: ні верхньої межі, ні рекомендованого значення, ні методики вимірювання.

Замість числа профіль побудував канал, яким число передають. Це процедура Delay Report у транспортному протоколі AVDTP: приймач повідомляє джерелу власну затримку, щоб той міг посунути відео. Формат поля описаний одним реченням — значення затримки їде двома байтами в десятих частках мілісекунди.

Роздільність — десята частка мілісекунди, розрядність — два байти. Максимум, який туди влазить, дорівнює 65535 ÷ 10 = 6553,5 мс. Протокол зарезервував місце під шість із половиною секунд затримки навушників. Це не прогноз і не типове значення, а те, що проєктувальники вважали за потрібне вмістити.

У таблиці 5.3 профілю A2DP роль ініціатора звіту про затримку обов'язкова для приймача (M), а роль приймальної сторони в джерелі — необов'язкова (O). Навушники зобов'язані сказати, наскільки вони спізнюються. Телефон не зобов'язаний це слухати. Одна й та сама пара тому й синхронна з одним апаратом і розсинхронізована з іншим: механізм узгодження є, але він однобічний за вимогливістю.

Скільки додає саме кодування

Ланку кодування виходить порахувати з параметрів, які профіль рекомендує сам. Для обов'язкового кодека SBC у таблиці 4.7 наведені рекомендовані налаштування енкодера, і серед них — довжина блоку 16 при 8 піддіапазонах. Один кадр SBC накриває 16 × 8 = 128 відліків. На 44,1 кГц — цю частоту дискретизації декодер приймача зобов'язаний підтримувати за профілем — кадр триває 128 ÷ 44100 = 0,0029 секунди, тобто 2,9 мс.

Кодер не може випустити кадр, поки не набрав усі 128 відліків.

LE Audio вперше виносить цю величину в текст. У специфікації кодека LC3 є параметр Total Codec Algorithmic Delay — сума тривалості кадру й попереднього перегляду сигналу, потрібного перетворенню MDCT. За таблицею 3.1: при кадрі 10 мс перегляд забирає 2,5 мс, разом 12,5 мс; при кадрі 7,5 мс перегляд зростає до 4 мс, разом 11,5 мс.

Напрямок тут неочевидний: коротший кадр вимагає більшого попереднього перегляду й усе одно виграє за сумою. Виграш — рівно мілісекунда, і за неї платять бітрейтом, бо на коротший кадр припадає більше службової інформації.

За надійність в ефірі платять часом

Далі кадр треба довезти. У Basic Audio Profile є таблиця 5.2 з готовими наборами параметрів якості обслуговування, і конфігурація кодека 16_2 — LC3, 16 кГц, кадр 10 мс — стоїть у ній двічі. Дивитися треба на два середні стовпці: у першому з них — скільки разів хост рекомендує контролеру повторити пакет, у другому — скільки часу на доставку відведено.

Кодек той самий, бітрейт той самий, навушники ті самі. Різниця — у числі повторів: 2 проти 13. Кожен повтор коштує часу в ефірі, і стеля цього часу росте з 10 мс до 95 мс. Майже вдесятеро.

Третій стовпець — буфер на боці приймача. Розділ 7 описує його як час між опорною точкою синхронізації й початком відтворення кадру, і в це значення входять внутрішні шини приймача, робота кодека, затримки перетворення між цифрою й аналогом, будь-яка обробка звуку в застосунку. Тобто це не порожнє чекання, а весь запас на внутрішню кухню навушників. У всіх рядках обох наборів там стоїть 40 000 мкс — 40 мс.

Розділ 7.2 прямо каже, що загальна затримка системи — сума трьох доданків: обробка звуку в джерелі, час доставки, буфер приймача. Два останні беруться просто з таблиці: 95 + 40 = 135 мс для надійного набору проти 10 + 40 = 50 мс для швидкого. Перший специфікація називає, але не нормує: про нього сказано лише, що він залежить від конкретної реалізації. Ось звідки беруться «десятки мілісекунд» і чому вони так гуляють — не з якості радіоканалу, а з того, який рядок таблиці обрав виробник і скільки він поклав у ненормований перший доданок.

Що можна подивитися сьогодні

Найдоступніша перевірка — у налаштуваннях для розробників на Android, у пункті з кодеком Bluetooth-аудіо. Він показує, який кодек і яка частота дискретизації узгоджені прямо зараз. Перемикання там міняє тільки ланку кодування; ефір і буфер приймача воно не чіпає, і саме тому зміна кодека зсуває розсинхрон менше, ніж від неї чекають.

Друге — повзунок затримки звуку в телевізорі чи плеєрі. Подивіться не на його поточне положення, а на діапазон: він показує, у які межі виробник закладався.

І третє, якщо навушники заявляють LE Audio: пошукайте в описі тривалість кадру LC3. Число 7,5 мс замість 10 мс означає, що обрано конфігурацію з нижчою алгоритмічною затримкою кодека — ту саму різницю в одну мілісекунду з таблиці 3.1.

Профіль описує канал, а не навушники

Усі ці числа — стелі й параметри узгодження, а не паспорт вашої пари. Max_Transport_Latency каже, скільки часу в ефірі дозволено запросити, а не скільки його реально піде; Presentation_Delay каже, скільки приймач попросив, а не скільки він насправді буферизує. А наскрізної затримки — від кадру на екрані до звуку у вусі — не називає жоден із чотирьох документів. Фраза про залежність від реалізації стоїть у чинній редакції профілю досі, і це не прогалина, а рішення.