Через масовий випуск смартфонів без аудіороз'єму 3.5 мм бездротові Bluetooth-навушники для багатьох стали основним способом прослуховування музики та спілкування в режимі гарнітури.
Виробники бездротових пристроїв не завжди пишуть докладні характеристики товару, а статті про Bluetooth-аудіо в інтернеті суперечливі, місцями некоректні, не розповідають про всі особливості, і часто копіюють ту саму інформацію, що не відповідає дійсності.
Спробуємо розібратися з протоколом, можливостями Bluetooth-стеків ОС, навушників і колонок, Bluetooth-кодеків для музики та мовлення, з'ясуємо, що впливає на якість звуку і затримку, що передається, навчимося збирати і декодувати інформацію про підтримувані кодеки та інші можливості пристроїв.

TL, д-р:

• SBC - нормальний кодек
• Навушники мають свій еквалайзер і пост-процесинг на кожен кодек окремо
• aptX не настільки гарний, як про нього говорять рекламні новини
• LDAC - маркетингове фуфло
• Якість звуку в режимі розмови все ще низька
• У браузер можна вбудувати аудіоенкери на C, скомпілювавши в WebAssembly через emscripten, і вони не будуть особливо гальмувати.

Музика через Bluetooth

Функціональна складова Bluetooth задається профілями специфікаціями конкретних функцій. Передача музики в Bluetooth здійснюється за допомогою профілю передачі високоякісного однонаправленого аудіо A2DP. Стандарт A2DP був прийнятий у 2003 році, і з того часу кардинально не змінювався.
У рамках профілю стандартизовано 1 обов'язковий кодек низької обчислювальної складності SBC, створений спеціально для Bluetooth, та 3 додаткові. Також допускається використання недокументованих кодеків власної реалізації.

Станом на червень 2019 року ми знаходимося у коміксі xkcd з 14 A2DP-кодеками:

• SBC ← стандартизовано в A2DP, підтримується всіма пристроями
• MPEG-1/2 Layer 1/2/3 ← стандартизовані в A2DP: всім відомий MP3, що використовується в цифровому ТБ MP2, і невідомий MP1
• MPEG-2/4 AAC ← стандартизовано в A2DP
• ПРИВАБЛЕННЯ ← старий кодек від Sony, стандартизований в A2DP
• LDAC ← новий кодек від Sony
• APTX ← кодек із 1988 року
• aptXHD ← те саме, що aptX, тільки з іншими параметрами кодування
• aptX Низька затримка ← зовсім інший кодек, немає софтової реалізації
• aptX Адаптивний ← ще один кодек Qualcomm
• FastStream ← псевдокодек, двонаправлена ​​модифікація SBC
• HWA LHDC ← новий кодек від Huawei
• Samsung HD ← підтримується 2 пристроями
• Samsung Scalable ← підтримується 2 пристроями
• Samsung UHQ-BT ← підтримується 3 пристроями

Навіщо взагалі потрібні кодеки, запитаєте ви, коли у Bluetooth є EDR, що дозволяє передавати дані на швидкості 2 і 3 Мбіт/с, а для стиснутого двоканального 16-бітного PCM достатньо 1.4 Мбіт/с?

Передача даних через Bluetooth

У Bluetooth існує два типи даних: Asynchronous Connection Less (ACL) для асинхронної передачі без встановлення з'єднання, і Synchronous Connection Oriented (SCO), для синхронної передачі з попереднім узгодженням з'єднання.
Передача здійснюється з використанням схеми поділу часу та вибору каналу передачі на кожен пакет окремо (Frequency-Hop/Time-Division-Duplex, FH/TDD), для чого час ділиться на 625-мікросекундні інтервали, які називаються слотами (slot). Один із пристроїв веде передачу в парних номерах слотів, інший — у непарних. Пакет може займати 1, 3 або 5 слотів, залежно від розміру даних і встановленого типу передачі, в цьому випадку передача одним пристроєм ведеться в парних і непарних слотах до кінця передачі. Всього за секунду можна прийняти і відправити до 1600 пакетів, якщо кожен із них займає 1 слот, і обидва пристрої без зупинки щось передають і приймають.

2 і 3 Мбіт/с для EDR, які можна зустріти в анонсах і на сайті Bluetooth, є максимальною канальною швидкістю передачі всіх даних сумарно (включаючи технічні заголовки всіх протоколів, які потрібно інкапсулювати дані), у двох напрямках одночасно. Фактична швидкість передачі буде сильно відрізнятися.

Для передачі музики використовується асинхронний спосіб, майже завжди за допомогою пакетів типу 2-DH5 і 3-DH5, які несуть максимальну кількість даних в режимі EDR 2 і 3 мбіт/с відповідно, і займають 5 слотів тимчасового поділу ефіру.

Схематичне подання передачі з використанням 5 слотів одним пристроєм та 1 слота іншим (DH5/DH1):


Через принцип поділу ефіру за часом ми змушені чекати 625-мікросекундний тайм-слот після передачі пакета, якщо другий пристрій нам нічого не буде передавати або передає маленький пакет, і більше часу, якщо другий пристрій веде передачу великими пакетами. Якщо до телефону підключено більше одного пристрою (наприклад, навушники, годинник та фітнес-браслет), час передачі розділяється між ними всіма.

Необхідність інкапсуляції аудіо в спеціальні транспортні протоколи L2CAP і AVDTP забирає 16 байт від можливої ​​максимальної кількості корисного аудіонавантаження, що передається.

Тип пакету
Кількість слотів
Макс. у байт у пакеті
Макс. у байт корисного навантаження A2DP
Макс. бітрейт корисного навантаження A2DP

2-DH3
3
367
351
936 кбіт/с

3-DH3
3
552
536
1429 кбіт/с

2-DH5
5
679
663
1414 кбіт/с

3-DH5
5
1021
1005
2143 кбіт/с

1414 і 1429 кбіт/с точно недостатньо для передачі стисненого звуку в реальних умовах, із зашумленим діапазоном 2.4 ГГц та необхідністю передачі службових даних. EDR 3 Мбіт/с вимогливий до потужності передачі і шумів в ефірі, тому, навіть у режимі 3-DH5, комфортна передача PCM неможлива, постійно будуть короткочасні переривання, і все буде працювати тільки на відстані в пару метрів.
На практиці навіть 990 кбіт/с-аудіопотік (LDAC 990 kbit/s) передається важко.

Повернемося до кодеків.

SBC

Кодек є обов'язковим для всіх пристроїв, що підтримують стандарт A2DP. Найкращий і найгірший кодек одночасно.

Частота дискретизації
Розрядність
Бітрейт
Підтримка кодування
Підтримка декодування

16, 32, 44.1, 48 кГц
16 біт
10-1500 кбіт/с
Усіми пристроями
Усіми пристроями

SBC - простий і обчислювально швидкий кодек, з примітивною психоакустичною моделлю (застосовується тільки маскування тихих звуків), що використовує адаптивну модуляцію імпульсно-кодову (APCM).
Специфікація A2DP рекомендує до використання два профілю: Middle Quality та High Quality.


У кодека багато налаштувань, що дозволяють керувати алгоритмічною затримкою, кількістю семплів у блоці, алгоритмом розподілу бітів, але майже повсюдно використовуються одні й ті ж рекомендовані в специфікації параметри: Joint Stereo, 8 частотних смуг, 16 блоків в аудіофреймі, спосіб розподілу біт Loudness.
SBC підтримує динамічну зміну параметра Bitpool, який безпосередньо впливає на бітрейт. Якщо радіоефір забитий, пакети губляться або пристрої знаходяться на великій відстані, джерело аудіо може зменшувати Bitpool, доки зв'язок не нормалізується.

Виробники більшості навушників встановлюють максимальне значення параметра Bitpool 53, що обмежує бітрейт 328 кілобітами в секунду при використанні рекомендованого профілю.
Навіть якщо виробник навушників встановив максимальне значення Bitpool вище 53 (такі моделі зустрічаються, наприклад: Beats Solo³, JBL Everest Elite 750NC, Apple AirPods, також буває на деяких ресиверах та автомобільних головних пристроях), більшість ОС не дозволять використовувати підвищені бітрейти через встановленого внутрішнього обмеження значення у Bluetooth-стеках.
Крім того, деякі виробники задають низьке максимальне значення Bitpool для деяких пристроїв. Наприклад, у Bluedio T воно дорівнює 39, у Samsung Gear IconX - 37, що дає погану якість звуку.

Штучні обмеження з боку розробників Bluetooth-стеків, найімовірніше, виникли внаслідок несумісності деяких пристроїв з великими значеннями Bitpool або нетиповими профілями, навіть якщо вони повідомляли про їх підтримку та недостатню кількість тестів під час сертифікації. Авторам Bluetooth-стеків простіше було обмежитися узгодженням рекомендованого профілю, а не створювати бази некоректних пристроїв (хоча зараз вони це роблять для інших функцій, що не коректно працюють).

SBC динамічно виділяє біти квантування для частотних смуг, діючи за принципом від нижніх до верхніх з різними ваговими коефіцієнтами. Якщо весь бітрейт використовувався на нижні та середні частоти, верхні частоти обріжуться (замість них буде тиша).

Приклад SBC 328 кбіт/с. Вгорі – оригінал, внизу – SBC, періодично відбувається перемикання між доріжками. Для аудіо у відеофайлі використовується кодек стиснення без втрат FLAC. Використання FLAC у контейнері mp4 офіційно не стандартизовано, тому не факт, що ваш браузер відтворить його, але має працювати в останніх версіях десктопних Chrome та Firefox. Якщо у вас немає звуку, можете завантажити файл та відкрити у повноцінному відеоплеєрі.
ZZ Top - Sharp Dressed Man

На спектрограмі видно момент перемикання: SBC періодично ріже тихі звуки вище 17.5 кГц, і не виділяє бітів для лінії вище 20 кГц. Повна спектрограма доступна на кліку (1.7 МБ).

Я не чую різниці між оригіналом та SBC на цьому треку.

Візьмемо щось новіше, і змоделюємо аудіо, яке вийшло б при використанні навушників Samsung Gear IconX з Bitpool 37 (вгорі — вихідний сигнал, внизу — SBC 239 кбіт/с, звук у FLAC).
Mindless Self Indulgence - Witness

Я чую тріск, менший стереоефект і неприємне «цокання» вокалу у високих частотах.

Хоча SBC і дуже гнучкий кодек, може бути налаштований під низькі затримки, дає відмінну якість аудіо на високих бітрейтах (452+ кбіт/с) і цілком хорошу для більшості людей на стандартному High Quality (328 кбіт/с), тому що стандарт A2DP не задає фіксованих профілів (а дає тільки рекомендації), розробники стеків встановили штучні обмеження на Bitpool, параметри аудіо, що передається, не відображаються в інтерфейсі користувача, а виробники навушників вільні виставляти свої налаштування і ніколи не вказують значення Bitpool в технічних прославився низькою якістю звуку, хоч це й не є проблемою кодека як такого.
Параметр Bitpool прямо впливає на бітрейт лише у межах одного профілю. Те саме значення Bitpool 53 може давати як бітрейт 328 кбіт/с при рекомендованому профілі High Quality, так і 1212 кбіт/с з Dual Channel і 4 частотними смугами, через що автори ОС, крім обмежень на Bitpool, встановлюють обмеження ще та на Bitrate. Як мені бачиться, така ситуація виникла через недоробку стандарту A2DP: потрібно було узгоджувати бітрейт, а не Bitpool.

Таблиця підтримки можливостей SBC у різних ОС:

ОС
Підтримувані частоти дискретизації
Обмеження макс. Bitpool
Обмеження макс. Bitrate
Типовий Bitrate
Динамічна підстроювання Bitpool

Windows 10
44.1 кГц
53
512 кбіт/с
328 кбіт/с
✓*

Linux (BlueZ + PulseAudio)
16, 32, 44.1, 48 кГц
64 (при вхідному підключенні), 53 (при вихідному)
немає обмеження
328 кбіт/с
✓*

MacOS High Sierra
44.1 кГц
64 за замовчуванням 53***
Невідомо
328 кбіт/с
✗

Android 4.4-9
44.1/48 кГц**
53
328 кбіт/с
328 кбіт/с
✗

Android 4.1-4.3.1
44.1, 48 кГц**
53
229 кбіт/с
229 кбіт/с
✗

Blackberry OS 10
48 кГц
53
немає обмеження
328 кбіт/с
✗

* Bitpool лише зменшується, але не збільшується автоматично, у разі покращення умов передачі. Для відновлення Bitpool потрібно зупинити відтворення, зачекати кілька секунд і заново запустити аудіо.
** Значення за замовчуванням залежить від параметрів стека, зазначених під час компіляції мікропрограми. В Android 8/8.1 частота тільки 44.1 кГц, або 48 кГц, залежно від налаштувань при компіляції, в інших версіях підтримуються 44.1 кГц і 48 кГц одночасно.
*** Bitpool можна підняти у Bluetooth Explorer.

aptX та aptX HD

aptX - простий і обчислювально швидкий кодек, без психоакустики, що використовує адаптивну диференціальну імпульсно-кодову модуляцію (ADPCM). З'явився приблизно 1988 року (дата подачі патенту датована лютим 1988 р.), до Bluetooth використовувався переважно у професійній бездротовій аудіоапаратурі. На даний момент належить компанії Qualcomm, що вимагає ліцензування та ліцензійних відрахувань. Станом на 2014 рік: $6000 одноразово і ≈$1 за кожен пристрій, для партій до 10000 пристроїв (джерело, Стор. 16).
aptX і aptX HD — той самий кодек, з різними профілями кодування.

Кодек має лише один параметр — вибір частоти дискретизації. Ще є, правда, вибір кількості/режиму каналів, але у всіх відомих мені пристроях (70+ штук) підтримується виключно Stereo.

Кодек
Частота дискретизації
Розрядність
Бітрейт
Підтримка кодування
Підтримка декодування

APTX
16, 32, 44.1, 48 кГц
16 біт
128/256/352/384 кбіт/с (залежно від частоти дискретизації)
Windows 10 (десктопна та мобільна), macOS, Android 4.4+/7*, Blackberry OS 10
Широким числом аудіопристроїв (апаратно)

* Версії до 7 вимагають модифікації Bluetooth-стеку. Кодек підтримується, тільки якщо виробник Android-пристрою ліцензував використання кодека Qualcomm (якщо в ОС є бібліотеки кодування).

aptX поділяє аудіо на 4 частотні смуги і квантує їх однією і тією ж кількістю біт постійно: 8 біт для 0-5.5 кГц, 4 біти для 5.5-11 кГц, 2 біти для 11-16.5 кГц, 2 біти для 16.5-22 кГц цифри частоти дискретизації 44.1 кГц).

Приклад aptX-аудіо (вгорі - вихідний сигнал, внизу - aptX, спектрограми лише лівих каналів, звук у FLAC):

Верхні частоти стали трохи червонішими, але різниці не чути.

Через фіксований розподіл бітів квантування, кодек не може «перенести біти» на ті частоти, які найбільше їх потребують. На відміну від SBC, aptX не «обрізатиме» частоти, а додаватиме в них шуми квантування, зменшуючи динамічний діапазон аудіо.

Не слід вважати, що використання, наприклад, 2 біт смуги зменшує динамічний діапазон до 12 дБ: ADPCM дозволяє використовувати до 96 дБ динамічного діапазону навіть при використанні 2 біт квантування, але тільки при певному сигналі.
ADPCM зберігає різницю числового подання між поточним і наступним відліком, замість запису абсолютного значення, як PCM. Це дозволяє зменшити вимоги до кількості біт, необхідні зберігання такої ж (без втрат) або практично такої ж (з відносно невеликою помилкою округлення) інформації. Для зменшення помилок округлення використовуються таблиці коефіцієнтів.
При створенні кодека автори розраховували коефіцієнти ADPCM на наборі музичних аудіофайлів. Чим ближче аудіосигнал до набору музики, на яких будувалися таблиці, тим менше помилок квантування (шумів) створює aptX.

Через це синтетичні тести завжди будуть давати результат гірше, ніж музика. Я зробив спеціальний синтетичний приклад, на якому aptX показує погані результати – синусоїда частотою 12.4 кГц (вгорі – вихідний сигнал, внизу – aptX. Звук у FLAC. Зменшіть гучність!):

Графік спектру:


Виразно чути шуми.

Однак, якщо згенерувати синусоїду з меншою амплітудою, щоб вона була тихішою, шуми також стануть тихішими, що говорить про широкий динамічний діапазон:

Щоб почути різницю між оригінальним музичним треком та стислим, можна інвертувати один із сигналів та скласти треки поканально. Такий підхід, в загальному випадку, некоректний, і не давав би осудного результату з складнішими кодеками, але саме для ADPCM цілком підходить.
Різниця між оригіналом та aptX
Середня квадратична різниця сигналів на рівні -37.4 дБ, що не багато для такої компресованої музики.

aptXHD

aptX HD не є самостійним кодеком – це покращений профіль кодування кодека aptX. Зміни торкнулися кількості біт, відведених для кодування частотних діапазонів: 10 біт для 0-5.5 кГц, 6 біт для 5.5-11 кГц, 4 біти для 11-16.5 кГц, 4 біти для 16.5-22 кГц (цифри для 44.1.

Кодек
Частота дискретизації
Розрядність
Бітрейт
Підтримка кодування
Підтримка декодування

aptXHD
16, 32, 44.1, 48 кГц
24 біта
192/384/529/576 кбіт/с (залежно від частоти дискретизації)
Android 8+*
Деяким аудіопристроєм (апаратно)

* Версії до 7 вимагають модифікації Bluetooth-стеку. Кодек підтримується, тільки якщо виробник Android-пристрою ліцензував використання кодека Qualcomm (якщо в ОС є бібліотеки кодування).

Менш поширений, ніж aptX: мабуть, вимагає окремого ліцензування Qualcomm, і окремих ліцензійних відрахувань.

Повторимо приклад із синусоїдою на 12.4 кГц:


Набагато краще, ніж з aptX, але все одно шумно.

aptX Низька затримка

Кодек Qualcomm, що не має спільного зі стандартними aptX і aptX HD, судячи з нечисленної інформації від людей, причетних до його розробки. Призначений для інтерактивної передачі аудіо з низькою затримкою (фільми, ігри), де затримка звуку не може підлаштовуватися програмно. Відомі софтові реалізації енкодерів та декодерів відсутні, підтримується виключно трансмітерами, ресиверами, навушниками та колонками, але не смартфонами та комп'ютерами.

Частота дискретизації
Бітрейт
Підтримка кодування
Підтримка декодування

44.1 кГц
276/420 кбіт/с
Деякі трансмітери (апаратно)
Деяким аудіопристроєм (апаратно)

AAC

AAC, або Advanced Audio Coding — обчислювально складний кодек із серйозною психоакустичною моделлю. Набув широкого поширення для аудіо в інтернеті, друге за популярністю після MP3. Вимагає ліцензування та ліцензійних відрахувань: $15000 одноразово (або $1000 для компаній з менш ніж 15 працівниками) + $0.98 за перші 500000 пристроїв (джерело).
Кодек стандартизований в рамках специфікацій MPEG-2 та MPEG-4, і всупереч частому оману, Apple не належить.

Частота дискретизації
Бітрейт
Підтримка кодування
Підтримка декодування

8 - 96 кГц
8 - 576 кбіт/с (для стерео), 256 - 320 кбіт/с (типовий для Bluetooth)
macOS, Android 7+*, iOS
Широким числом аудіопристроїв (апаратно)

* лише на пристроях, виробники яких заплатили ліцензійні відрахування

У iOS і macOS використовується найкращий на сьогоднішній день кодувальник Apple AAC, що забезпечує максимально можливу якість аудіо. В Android використовується другий за якістю кодувальник Fraunhofer FDK AAC, але можуть використовуватися різні апаратні, вбудовані в платформу (SoC), з невідомою якістю кодування. За недавніми тестами сайту SoundGuys, якість кодування AAC різними Android-телефонами сильно відрізняється:

У більшості бездротових аудіопристроїв для AAC встановлений максимальний бітрейт 320 кбіт/с, деякі підтримують лише 256 кбітс. Інші бітрейти зустрічаються вкрай рідко.
AAC забезпечує відмінну якість на бітрейтах 320 і 256 кбіт/с, але схильний втрат послідовного кодування вже стисненого контентуОднак, почути будь-які відмінності з оригіналом на iOS при бітрейті 256 кбіт/с складно навіть при декількох послідовних кодуваннях, при одиночному кодуванні, наприклад, MP3 320 кбіт/с в AAC 256 кбіт/с втратами можна знехтувати.
Як і у випадку з іншими Bluetooth-кодеками, будь-яка музика спочатку декодується, потім кодується кодеком. При прослуховуванні музики у форматі AAC вона спочатку декодується засобами ОС, потім кодується в AAC ще раз для передачі через Bluetooth. Це необхідно для мікшування декількох аудіопотоків, наприклад, музики та повідомлення про нове повідомлення. iOS – не виняток. В інтернеті можна знайти безліч тверджень про те, що на iOS музика у форматі AAC не транскодується під час передачі через Bluetooth, що неправильно.

MP1/2/3

Кодеки сімейства MPEG-1/2 Part 3 складаються з відомого MP3, що широко використовується, менш поширеного MP2 (застосовується переважно в цифровому ТБ і радіо), і зовсім невідомого MP1.

Старі кодеки MP1 і MP2 не підтримуються зовсім: мені не вдалося знайти ні одні навушники і жоден Bluetooth-стек, який кодував або декодував їх.
Декодування MP3 підтримується деякими навушниками, але кодування не підтримується в жодному стеку сучасних операційних систем. Начебто, сторонній стек BlueSoleil для Windows може кодувати в MP3, якщо вручну змінити конфігураційний файл, але у мене його установка призводить до BSoD на Windows 10. Висновок - кодеком фактично не можна користуватися для Bluetooth-аудіо.
Раніше, у 2006-2008 роках, до поширення стандарту A2DP у пристроях, люди слухали MP3-музику на гарнітурі Nokia BH-501 через програму MSI BluePlayer, яка була доступна на Symbian та Windows Mobile. У той час архітектура ОС смартфонів дозволяла отримувати доступ до багатьох низькорівневих функцій, а на Windows Mobile можна було встановлювати сторонні Bluetooth-стеки.

Останній патент кодека MP3 минув, використання кодека не вимагає ліцензійних відрахувань з 23 квітня 2017 року.

Якщо тривалий-запуск patent mentioned in aforementioned references is take as ameasure, then MP3 technology became patent-free in the United States on 16 April 2017 when US Patent 6,009,399, held by and administered by Tepi

Джерело: www.iis.fraunhofer.de/en/ff/amm/prod/audiocodec/audiocodecs/mp3.html

Частота дискретизації
Бітрейт
Підтримка кодування
Підтримка декодування

16 - 48 кГц
8 - 320 кбіт/с
Ніде не підтримується
Деяким аудіопристроєм (апаратно)

LDAC

Новий «Hi-Res»-кодек від Sony, що активно просувається, підтримує частоти дискретизації до 96 кГц і 24-бітову розрядність, з бітрейтом до 990 кбіт/с. Рекламується як аудіофільський кодек, як заміна існуючим Bluetooth-кодекам. Має функцію адаптивного підстроювання бітрейту, залежно від умов радіоефіру.

Енкодер LDAC (libldac) входить у стандартне постачання Android, тому кодування підтримується на будь-якому Android-смартфоні, починаючи з 8 версії ОС. Програмні декодери у вільному доступі відсутні, специфікація кодека недоступна широкому загалу, однак, на перший погляд на енкодер, внутрішній пристрій кодека схожий на ATRAC9 — кодеком від Sony, що використовується в PlayStation 4 та Vita: обидва працюють у частотному діапазоні, використовують модифіковане дискретне косинус-перетворення (MDCT) та стиск із застосуванням алгоритму Хаффмана.

Підтримка LDAC представлена ​​лише навушниками від Sony. Можливість декодування LDAC іноді зустрічається на навушниках та ЦАП інших виробників, але дуже рідко.

Частота дискретизації
Бітрейт
Підтримка кодування
Підтримка декодування

44.1 - 96 кГц
303/606/909 кбіт/с (для 44.1 та 88.2 кГц), 330/660/990 кбіт/с (для 48 та 96 кГц)
Android 8 +
Деякі навушники Sony та одиничні пристрої інших виробників (апаратно)

Маркетинг LDAC як Hi-Res-кодек шкодить його технічною складовою: безглуздо витрачати бітрейт на передачу частот, що не чують людським вухом, і підвищену розрядність, поки його не вистачає для передачі CD-якості (44.1/16) без втрат. На щастя, кодек має два режими роботи: передачу CD-аудіо і передачу Hi-Res-аудіо. У першому випадку повітрям передається тільки 44.1 кГц/16 біт.

Оскільки програмного декодера LDAC немає у вільному доступі, протестувати кодек без додаткових пристроїв, що розкодують LDAC, неможливо. За результатами тесту LDAC на ЦАП з його підтримкою, який підключили інженери сайту SoundGuys.com через цифровий вихід і записали звук, що видається на тестових сигналах, LDAC 660 і 990 кбіт/с в режимі CD-якості забезпечує співвідношення сигнал/шум трохи краще такого у aptX HD.

Джерело: www.soundguys.com/ldac-ultimate-bluetooth-guide-20026

LDAC також підтримує динамічний бітрейт поза встановленими профілями – від 138 кбіт/с до 990 кбіт/с, але, наскільки можу судити, в Android використовуються тільки стандартизовані профілі 303/606/909 та 330/660/990 кбіт/с.

Інші кодеки

Інші A2DP-кодеки не набули широкого поширення. Їхня підтримка або практично повністю відсутня, або є тільки на певних моделях навушників та смартфонів.
Стандартизований в A2DP кодек ATRAC жодного разу не використовувався як Bluetooth-кодек навіть самими Sony, кодеки Samsung HD, Samsung Scalable і Samsung UHQ-BT мають дуже обмежену підтримку з боку передавальних і одержувальних пристроїв, а HWA LHDC - занадто новий, і підтримується всього трьома(?) пристроями.

Підтримка кодеків аудіопристроями

Не всі виробники публікують точну інформацію про кодеки, які підтримують бездротові навушники, колонки, ресивери або трансмітери. Іноді буває так, що підтримка певного кодека є тільки на передачу, але не на прийом (актуально для комбінованих трансмітерів-ресиверів), хоча виробник заявляє просто про «підтримку», без приміток (припускаю, в цьому винне окреме ліцензування енкодерів та декодерів деяких кодеків) ). У найдешевших пристроях можна не виявити заявлену підтримку aptX.

На жаль, в інтерфейсах більшості ОС ніде не відображається кодек, що використовується. Інформація про це є тільки в Android, починаючи з 8 версії, та macOS. Однак, навіть у цих ОС будуть відображатися лише кодеки, які підтримує як телефон/комп'ютер, так і навушники.

Як дізнатися, які кодеки підтримує пристрій? Записати та проаналізувати дамп трафіку з параметрами узгодження A2DP!
Зробити це можна в Linux, MacOS та Android. У Linux можна скористатися Wireshark або hcidump, у macOS - Bluetooth Explorer, а в Android - штатною функцією збереження Bluetooth HCI-дампа, яка доступна в інструментах розробника. Ви отримаєте дамп у форматі btsnoop, який можна завантажити у аналізатор Wireshark.
Зверніть увагу: коректний дамп можна отримати тільки підключившись з телефону/комп'ютера до навушників/колонки (хоч би як курйозно це звучало)! Навушники можуть самостійно встановлювати з'єднання з телефоном, і в цьому випадку вони вимагатимуть список кодеків у телефону, а не навпаки. Щоб гарантовано записати коректний дамп, спочатку розірвіть пару з пристроєм, а потім, під час запису дампа, сполучіть телефон із навушниками.

Використовуйте наступний фільтр, щоб відсіяти нерелевантний трафік:

btavdtp.signal_id

В результаті ви повинні побачити щось схоже:

На кожному пункті команди GetCapabilities можна натиснути і переглянути докладні характеристики кодека.

Wireshark знає не всі ідентифікатори кодеків, тому частину кодеків доведеться розшифровувати вручну, дивлячись у таблиці ідентифікаторів нижче:

Mandatory:
0x00 - SBC

Optional:
0x01 - MPEG-1,2 (aka MP3)
0x02 - MPEG-2,4 (aka AAC)
0x04 - ATRAC

Vendor specific:
0xFF 0x004F 0x01   - aptX
0xFF 0x00D7 0x24   - aptX HD
0xFF 0x000A 0x02   - aptX Low Latency
0xFF 0x00D7 0x02   - aptX Low Latency
0xFF 0x000A 0x01   - FastStream
0xFF 0x012D 0xAA   - LDAC
0xFF 0x0075 0x0102 - Samsung HD
0xFF 0x0075 0x0103 - Samsung Scalable Codec
0xFF 0x053A 0x484C - Savitech LHDC

0xFF 0x000A 0x0104 - The CSR True Wireless Stereo v3 Codec ID for AAC
0xFF 0x000A 0x0105 - The CSR True Wireless Stereo v3 Codec ID for MP3
0xFF 0x000A 0x0106 - The CSR True Wireless Stereo v3 Codec ID for aptX

Щоб не аналізувати дампи вручну, я зробив сервіс, який проаналізує все автоматично: btcodecs.valdikss.org.ru

Порівняння кодеків. Який кодек кращий?

Кожен кодек має свої переваги і недоліки.
aptX і aptX HD використовують жорстко задані профілі, які не можна змінити без модифікації енкодера та декодера. Ні виробник телефону, ні виробник навушників не може змінити бітрейт або коефіцієнти кодування aptX. Власник кодека, Qualcomm, видає референсний енкодер у вигляді бібліотеки. Ці факти – сильна сторона aptX – ви наперед знаєте, якої якості звук ви отримаєте, без будь-яких «але».

SBC, навпаки, має безліч параметрів, що настроюються, динамічний бітрейт (енкодер може зменшувати параметр bitpool, якщо радіоефір завантажений), і не має жорстко заданих профілів, а тільки рекомендовані «середня якість» і «висока якість», які додали в специфікацію A2DP в 2003 року. "Висока якість" вже не така висока за сучасними мірками, а більшість Bluetooth-стеків не дозволяють використовувати параметри краще, ніж у профілі "висока якість", хоча технічних обмежень для цього немає.
Bluetooth SIG не має референсного енкодера SBC у вигляді бібліотеки, і виробники реалізують його самостійно.
Це – слабкі сторони SBC – ніколи наперед не ясно, якої якості звуку очікувати від конкретного пристрою. SBC може видавати як низьку, так і дуже високу якість звуку, але останнє недосяжно без відключення або обходу штучних обмежень стеків Bluetooth.

Ситуація з AAC неоднозначна: з одного боку, теоретично кодек повинен видавати якість, яка не відрізняється від оригіналу, але практикою, судячи з тестів лабораторії SoundGuys на різних Android-пристроях, це не підтверджується. Найімовірніше, вина на низькоякісних апаратних аудіоенкодерах, вбудованих у різні чіпсети телефонів. Має сенс використовувати AAC тільки на пристрої Apple, а на Android обмежитися aptX і LDAC.

Апаратура, що підтримує альтернативні кодеки, як правило, вищої якості, просто тому, що для дешевих низькоякісних пристроїв немає сенсу платити ліцензійні відрахування для використання цих кодеків. На мої тести, SBC звучить дуже добре на якісній апаратурі.

Я зробив веб-сервіс, що кодує аудіо в SBC, aptX і aptX HD у реальному часі, прямо у браузері. За допомогою нього ви зможете тестувати ці аудіокодеки без фактичної передачі аудіо по Bluetooth, на будь-яких дротових навушниках, колонках та вашій улюбленій музиці, а також змінювати параметри кодування прямо під час відтворення аудіо:
btcodecs.valdikss.org.ru/sbc-encoder
Сервіс використовує бібліотеки кодування SBC з проекту BlueZ і libopenaptx з ffmpeg, які скомпільовані в WebAssembly та JavaScript з C, через emscripten, для виконання у браузері. Хто міг мріяти про таке майбутнє!

Ось як це виглядає:

Зверніть увагу, як змінюється рівень шуму після 20 кгц у різних кодеків. В оригінальному MP3-файлі частоти від 20 кГц відсутні.

Спробуйте переключити кодеки та оцінити, чи чуєте ви різницю між оригіналом, SBC 53 Joint Stereo (стандартний та найпоширеніший профіль), та aptX/aptX HD.

Я чую різницю між кодеками в навушниках!

Люди, які не чують різниці між кодеками під час тестування через веб-сервіс, запевняють, що чують її під час прослуховування музики у бездротових навушниках. На жаль, це не прикол і не ефект плацебо: різниця справді чутна, проте вона викликана не відмінностями кодеків.

Переважна більшість чіпсетів Bluetooth-аудіо, що використовуються в бездротових пристроях, що приймають, оснащуються цифровим обробником сигналів (Digital signal processor, DSP), який реалізує еквалайзер, компандер, розширювач стерео та інші речі, покликані поліпшити (або змінити) звук. Виробники Bluetooth-апаратури можуть налаштувати DSP для кожного кодека окремо, і при перемиканні між кодеками слухачеві здаватиметься, що він чує відмінність роботи кодеків, коли насправді слухає різні налаштування DSP.

Конвейєр обробки звуку DSP Kalimba у чіпах виробництва CSR/Qualcomm

Активація різних функцій DSP для кожного кодека та виходу окремо

Деякі пристрої преміального сегмента комплектуються програмою, що дозволяє налаштовувати параметри DSP, але більшість дешевих навушників не мають такої можливості, і користувачі не можуть відключити постпроцесинг звуку штанти засобами.

Функціональні особливості пристроїв

Сучасна версія стандарту A2DP має функцію «абсолютного регулювання гучності» — керування гучністю пристрою спеціальними командами протоколу AVRCP, що регулює посилення вихідного каскаду замість програмного зменшення гучності аудіопотоку. Якщо під час зміни гучності навушників зміна не синхронізується з гучністю на телефоні, це означає, що навушники або телефон не підтримують цю функцію. У такому разі, має сенс слухати музику завжди з максимальною гучністю на телефоні, регулюючи фактичну гучність кнопками навушників — у цьому випадку співвідношення сигнал/шум буде кращим, і якість аудіо повинно бути вище.
Насправді ж бувають сумні ситуації. На моїх навушниках RealForce OverDrive D1 для SBC включений сильний компандер, і збільшення гучності призводить до підвищення рівня тихих звуків, а гучність гучних звуків не змінюється (відбувається компресія сигналу). Через це доводиться встановлювати гучність на комп'ютері приблизно наполовину, у разі ефекту компресії практично немає.
За моїми спостереженнями, всі навушники з додатковими кодеками підтримують функцію абсолютного регулювання гучності, мабуть, це одна з вимог для сертифікації кодеків.

Деякі навушники підтримують підключення двох пристроїв одночасно. Це дозволяє, наприклад, слухати музику з комп'ютера та приймати дзвінки з телефону. Однак слід знати, що в цьому режимі відключаються альтернативні кодеки і використовується лише SBC.

Функція AVDTP 1.3 Delay Reporting дозволяє навушникам повідомляти затримку пристрою, що передає, з якої фактично відтворюється звук. Це дозволяє підлаштовувати синхронізацію аудіо з відео під час перегляду відеофайлів: при проблемах з передачею по радіоефіру, аудіо не відставатиме від відео, а навпаки, відео гальмуватиметься відеоплеєром, поки аудіо та відео знову не синхронізуються.
Функція підтримується багатьма навушниками, Android 9+ та Linux із PulseAudio 12.0+. Про підтримку функції на інших платформах мені невідомо.

Двонаправлений зв'язок через Bluetooth. Передача голосу.

Для передачі голосу в Bluetooth використовується Synchronous Connection Oriented (SCO) - синхронна передача з попереднім узгодженням з'єднання. Режим дозволяє передавати звук і голос строго по порядку, з симетричною швидкістю відправлення та прийому, без очікування підтвердження передачі та перенаправлення пакетів. Це знижує загальну затримку передачі аудіо через радіоканал, але накладає серйозні обмеження на кількість даних, що передаються за одиницю часу, і негативно позначається на якості.
Коли використовується цей режим, голос і аудіо передаються з однаковою якістю.
На жаль, станом на 2019 рік якість передачі мови через Bluetooth все ще низька, і незрозуміло, чому Bluetooth SIG з цим нічого не робить.

CVSD

Базовий кодек передачі мови CVSD був стандартизований у 2002 році, і підтримується всіма пристроями двонаправленого зв'язку через Bluetooth. Він забезпечує передачу аудіо з частотою дискретизації 8 кГц, що відповідає якості звичайної дротової телефонії.

Приклад запису в цьому кодеку.

mSBC

Додатковий кодек mSBC був стандартизований у 2009 році, а у 2010 вже з'явилися чіпи, які використовують його для передачі голосу. mSBC широко підтримується різними пристроями.
Це не самостійний кодек, а звичайний SBC зі стандарту A2DP, з фіксованим профілем кодування: 16 кГц, моно, bitpool 26.

Приклад запису в цьому кодеку.

Не блиск, але набагато краще, ніж CVSD, проте все ще неприємно використовувати його для спілкування через інтернет, особливо коли ви використовуєте навушники для спілкування в грі - звук гри теж буде передаватися з частотою дискретизації в 16 кГц.

FastStream Компанія CSR вирішила розвинути ідею перевикористання SBC. Щоб обійти обмеження протоколу SCO та використовувати більш високі бітрейти, CSR пішли іншим шляхом — впровадили підтримку двостороннього SBC-аудіо в стандарт передачі одностороннього аудіо A2DP, стандартизували профілі кодування, і назвали це FastStream.

FastStream передає в динаміки стереозвук 44.1 або 48 кГц з бітрейтом 212 кбіт/с, а для передачі аудіо з мікрофона використовується моно, 16 кГц, з бітрейтом 72 кбіт/с (трохи краще, ніж у mSBC). Такі параметри краще підходять для спілкування в онлайн-іграх - звук гри і співрозмовників буде якісний.

Приклад запису в цьому кодеку (+ звук з мікрофона, такий самий, як у mSBC).

Компанія вигадала цікавий милиця, але через те, що він суперечить стандарту A2DP, його підтримка є тільки в деяких трансмітерах компанії (які працюють як USB-аудіокарта, а не Bluetooth-пристрій), але підтримки в Bluetooth-стеках він не отримав, хоча кількість навушників з підтримкою FastStream не така вже й мала.

На даний момент підтримка FastStream в ОС є лише у вигляді патча для Linux'ового PulseAudio від розробника Pali Rohár, який не включений до основної галузі програми.

aptX Низька затримка

На превеликий подив, aptX Low Latency теж підтримує двонаправлене аудіо, реалізуючи такий же принцип, як у FastStream.
Використовувати цю особливість кодека не вийде ніде - підтримки декодування Low Latency немає в жодній ОС і в жодному відомому мені Bluetooth-стеку.

Bluetooth 5, Classic та Low Energy

Навколо специфікацій та версій Bluetooth виникла велика плутанина через наявність двох несумісних стандартів під одним брендом, обидва з яких широко застосовуються для різних цілей.

Існує два різні, не сумісні між собою протоколи Bluetooth: Bluetooth Classic і Bluetooth Low Energy (LE, він же Bluetooth Smart). Ще є третій протокол, Bluetooth High Speed, але він не розповсюджений і не використовується в побутових пристроях.

Починаючи з Bluetooth 4.0, зміни у специфікації стосувалися переважно Bluetooth Low Energy, а Classic-версія отримувала лише незначні покращення.

Список змін між Bluetooth 4.2 та Bluetooth 5:

9 CHANGES FROM v4.2 TO 5.0

9.1 НОВІ ФУНКЦІЇ

Звичайні нові особливості будуть введені в Bluetooth Core Specification 5.0 Release. Великі області здійснення:
• Slot Availability Mask (SAM)
• 2 Msym/s PHY for LE
• LE Long Range
• High Duty Cycle Non-Connectable Advertising
• LE Advertising Extensions
• LE Channel Selection Algorithm #2
9.1.1 Features Added in CSA5 - Integrated in v5.0
• Higher Output Power

Джерело: www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=421043 (Сторінка 291)

Тільки одна зміна торкнулася Classic-версії в рамках специфікації Bluetooth 5: додали підтримку технології Slot Availability Mask (SAM), покликану покращити поділ радіоефіру. Всі інші зміни стосуються тільки Bluetooth LE (та Higher Output Power теж).

Усі аудіопристрої використовують лише Bluetooth Classic. Навушники та колонки підключити через Bluetooth Low Energy неможливо: немає стандарту передачі аудіо з використанням LE. Стандарт A2DP, який використовується для передачі високоякісного аудіо, працює тільки через Bluetooth Classic, і аналога в LE йому не існує.

Висновок — придбати аудіопристрої з Bluetooth 5 тільки через нову версію протоколу безглуздо. Bluetooth 4.0/4.1/4.2 у контексті передачі аудіо буде працювати так само.
Якщо анонс нових навушників згадує подвоєний радіус роботи та зменшене енергоспоживання завдяки Bluetooth 5, то знайте – вони або самі не розуміються, або вводять вас в оману. Не дивно, адже навіть виробники Bluetooth-чіпів у своїх анонсах плутаються у відмінностях нової версії стандарту, а деякі Bluetooth 5-чіпи підтримують п'яту версію тільки для LE, а для Classic використовують 4.2.

Затримка передачі аудіо

Величина затримки (запізнювання) аудіо залежить від багатьох факторів: розміру буфера в аудіостеку, в Bluetooth-стеку і в бездротовому пристрої, що відтворює, алгоритмічної затримки кодека.

Затримка простих кодеків, на зразок SBC, aptX і aptX HD, зовсім невелика, і становить 3-6 мс, ніж можна знехтувати, але комплексні кодеки, на зразок AAC і LDAC, можуть давати відчутне запізнення. Алгоритмічна затримка AAC для 44.1 кгц становить 60 мс. LDAC - близько 30 мс (за грубим аналізом вихідного коду. Можу помилятися, але не сильно.)

Підсумкова затримка залежить від відтворювального пристрою, його чіпсету і буфера. Під час тестів я отримав розкид від 150 до 250 мс на різних пристроях (з кодеком SBC). Якщо припустити, що пристрої з підтримкою додаткових кодеків aptX, AAC та LDAC використовують якісні компоненти та невеликий розмір буфера, то отримаємо такі типові затримки:

SBC: 150-250 мс
aptX: 130-180 мс
AAC: 190-240 мс
LDAC: 160-210 мс

Нагадую: aptX Low Latency не підтримується в операційних системах, через що меншу затримку можна отримати лише зв'язкою трансмітер+ресивер або трансмітер+навушники/колонка, причому всі пристрої повинні підтримувати цей кодек.

Проблеми пристроїв, сертифікації та логотипів Bluetooth

Як відрізнити якісний аудіопристрій від дешевого виробу? На вигляд, перш за все!

У дешевих китайських навушників, колонок та ресиверів:

1. Відсутнє слово «Bluetooth» на коробці та пристрої, найчастіше використовується «Wireless» та «BT»
2. Відсутній логотип Bluetooth на коробці або пристрої
3. Немає синього миготливого світлодіода

Відсутність цих елементів говорить про те, що пристрій не проходил сертифікацію, а значить — потенційно низькоякісний і проблемний. Наприклад, навушники Bluedio не сертифіковані Bluetooth, і не повністю відповідають специфікації A2DP. Сертифікацію вони б не пройшли.

Розглянемо кілька пристроїв та коробок від них:

Це все – несертифіковані пристрої. В інструкції може бути логотип і назва технології Bluetooth, але найголовніше – щоб вони були на коробці та/або самому пристрої.

Якщо ваші навушники або колонка говорять "Ze bluetooth dewise is connecteda successfulle", це теж не говорить про їхню якість:

Висновок

Чи здатний Bluetooth повністю замінити дротові навушники та гарнітури? Здатний, але ціною низької якості в режимі розмови, збільшеною затримкою передачі звуку, яка може дратувати в іграх, і безлічі пропрієтарних кодеків, які вимагають ліцензійних відрахувань і збільшують кінцеву вартість смартфонів і навушників.

Маркетинг альтернативних кодеків дуже сильний: aptX і LDAC представляють у вигляді довгоочікуваної заміни «застарілого та поганого» SBC, який далеко не такий поганий, як про нього прийнято думати.

Як з'ясувалося, штучні обмеження Bluetooth-стеків на бітрейт SBC можна обійти так, що SBC не поступатиметься aptX HD. Я взяв ініціативу до своїх рук і зробив патч для прошивки LineageOS: Модифікуємо Bluetooth-стек для покращення звуку на навушниках без кодеків AAC, aptX та LDAC

Більше інформації можна знайти на сайтах SoundGuys и SoundExpert.

бонус: референсний енкодер SBC, інформація про бітстрім A2DP та тестові файли. Цей файл раніше був викладений на сайті Bluetooth публічно, але тепер він доступний тільки для SIG, що вступили в Bluetooth.

Джерело: habr.com