bluetooth le audio что это: что это такое и реализация в AOSP

Материал основан на разборе freecodecamp.org. Ниже — главное и практические шаги, которые можно быстро применить в работе.

---

С начала 2000-х Bluetooth стабильно занимает лидирующие позиции в беспроводном аудио, начиная с первых моно-гарнитур и заканчивая современными полностью беспроводными наушниками.

Однако базовая технология не успевала за реальными потребностями пользователей. Полностью беспроводные наушники, слуховые аппараты, предназначенные для постоянного ношения, совместное прослушивание аудио — все это не входило в планы разработчиков оригинального аудиостека Bluetooth.

LE Audio, разработанный Bluetooth SIG и утвержденный в 2022 году, представляет собой значительное обновление, заменяющее аудиостек Classic Bluetooth новой архитектурой, основанной на Bluetooth Low Energy. Он включает новый кодек (LC3), изохронные каналы, новые профили для упрощенной потоковой передачи и технологию широковещательной передачи Auracast.

Эти изменения помогают преодолеть старые ограничения звука, потребления энергии, многопоточной передачи и доступности.

В этой статье я делюсь разработкой AI бота «Хатипыч», созданного для анализа качества звонков менеджеров. Это может быть полезно, если вас интересует применение искусственного интеллекта в аудио- и коммуникационных технологиях, включая Bluetooth аудио.

В этой статье я делюсь разработкой AI бота «Хатипыч», созданного для анализа качества звонков менеджеров. Это может быть полезно, если вас интересует применение искусственного интеллекта в аудио- и коммуникационных технологиях, включая Bluetooth аудио.

Содержание

• Однажды в стране Bluetooth
• Проблемы Classic Bluetooth Audio
• LE Audio: герой, которого мы ждали
• Кодек LC3: лучший звук, меньше энергии, больше магии
• Изохронные каналы: новая инфраструктура
• Стек профилей LE Audio: многоуровневый пирог из спецификаций
• Многопоточное аудио: больше никакой ретрансляции через левый наушник
• Auracast: широковещательное аудио для всех
• LE Audio в Android/AOSP: реализация
• Архитектура AOSP: от приложения до антенны
• Реализация на стороне сервера (источника)
• Реализация на стороне клиента (приёмника)
• Конечный автомат, который всем управляет
• Собираем всё вместе: один день из жизни пакета LE Audio
• Подводим итоги

1. Однажды в стране Bluetooth

Представьте: 2003 год. Раскладные телефоны в моде. На рынке появляются первые Bluetooth-гарнитуры, и вдруг можно ходить, выглядя как киборг, и при этом отвечать на звонки.

Тот моно-звук телефонного качества обеспечивался маленькой штукой под названием HFP (Hands-Free Profile, профиль громкой связи) с использованием кодека CVSD на целых 64 кбит/с. Звучало так, будто собеседник говорит из подводной лодки, но зато — никаких проводов.

Перемотаем несколько лет вперёд. Появился A2DP (Advanced Audio Distribution Profile, профиль расширенного распределения аудио) для потоковой передачи музыки, принёсший нам SBC (Sub-Band Codec, кодек с разбиением на подполосы) — аудиокодек, эквивалентный Honda Civic. Не блестящий, не ужасный, справляется со своей задачей. A2DP дал нам стереопотоковую передачу музыки, и жизнь была хороша.

Какое-то время.

Bluetooth SIG (Special Interest Group, специальная группа по интересам) — консорциум тысяч компаний, управляющий Bluetooth, — продолжал итерировать классический аудиостек. Появились лучшие кодеки: aptX, AAC и LDAC. Но все они были построены поверх одной и той же древней инфраструктуры. Это как ремонтировать кухню, пока фундамент дома медленно трескается.

Аудиостек Bluetooth был построен на BR/EDR (Basic Rate/Enhanced Data Rate, базовая скорость/улучшенная скорость передачи данных) — радио «Classic Bluetooth». Это та же радиотехнология начала 2000-х, разработанная в то время, когда потоковая передача аудио с телефона на одну гарнитуру была вершиной инноваций. Никто не представлял полностью беспроводных наушников, слуховых аппаратов, напрямую получающих поток с телефона, или трансляции аудио на весь терминал аэропорта.

К концу 2010-х годов Bluetooth audio явно устарел. Очень сильно.

2. Проблемы классического Bluetooth-аудио

Давайте перечислим проблемы классического Bluetooth-аудио, потому что они весьма поучительны.

Проблема №1: Раздвоение личности двух профилей

У классического Bluetooth наблюдается дисбаланс функций: для прослушивания музыки требуется переключение на A2DP с SBC/AAC, а для звонков необходимо переходить на HFP, который использует другой кодек (CVSD или mSBC) и значительно ухудшает качество.

Задавались ли вы вопросом, почему беспроводные наушники хорошо звучат при воспроизведении музыки в Spotify, но возникают проблемы при звонке в Zoom? Это связано с переключением с A2DP на HFP. Разные профили используют разные кодеки и аудиопути, что может привести к заметным щелчкам при переключении.

Проблема №2: Проблема ретрансляции (полностью беспроводные наушники)

При использовании полностью беспроводных наушников, которые соединены между собой, классический Bluetooth сталкивается с серьезной проблемой: A2DP может одновременно передавать поток только на одно устройство.

Что на самом деле происходит с вашими дорогими наушниками:

• Телефон отправляет стереоаудиопоток на основной наушник (обычно правый)
• Основной наушник получает оба канала — левый и правый
• Затем он ретранслирует другой канал на вторичный наушник через отдельное Bluetooth-соединение

Такая архитектура ретрансляции имеет несколько важных последствий. Основной наушник расходует вдвое больше заряда батареи — он разряжается первым, и вы это наверняка замечали. Кроме того, возникает более высокая задержка на вторичном наушнике, возможны проблемы синхронизации между левым и правым каналами. И если основной наушник разрядится или потеряет соединение, оба наушника замолчат.

Проблема №3: Высокое энергопотребление

BR/EDR разрабатывался в эпоху, когда «низкое энергопотребление» означало «работает от батареек AA». Потоковая передача аудио через классический Bluetooth относительно энергозатратна: радиомодулю приходится поддерживать постоянное высокополосное соединение. Для таких устройств, как слуховые аппараты, которым нужно работать весь день от крошечных батареек, это было неприемлемо.

Проблема №4: Только один к одному

Классическое Bluetooth-аудио по своей сути является точка-точка. Один источник, один приёмник — или в лучшем случае очень костыльная реализация «двойного аудио», при которой телефон поддерживает два отдельных A2DP-соединения. Нет никакой возможности транслировать аудио нескольким слушателям одновременно без установки индивидуального соединения с каждым из них.

Представьте, что вы находитесь у выхода в аэропорту и хотите транслировать объявления о посадке в наушники всех присутствующих. С классическим Bluetooth пришлось бы сопрягаться с устройством каждого человека по отдельности. Удачи с этим у выхода B47.

Проблема №5: Отсутствие стандарта для слуховых аппаратов

До появления LE Audio не существовало официального стандарта Bluetooth для слуховых аппаратов. Apple создала собственный проприетарный протокол MFi (Made for iPhone) для слуховых аппаратов. Google создала ASHA (Audio Streaming for Hearing Aid, потоковая передача аудио для слуховых аппаратов) — полупроприетарное решение на основе BLE для Android. Ни то ни другое не являлось официальным стандартом Bluetooth, а совместимость была… назовём это «желаемой».

3. LE Audio: герой, которого мы ждали

В январе 2020 года на CES Bluetooth SIG представила LE Audio — полностью переосмысленный подход к Bluetooth-аудио, построенный поверх Bluetooth Low Energy (BLE) вместо классического BR/EDR.

Основные транспортные функции (изохронные каналы, EATT, LE Power Control) вошли в спецификацию Bluetooth Core Specification v5.2 в конце 2019 — начале 2020 года. Однако полный набор профилей и сервисов LE Audio был завершён лишь 12 июля 2022 года, когда Bluetooth SIG официально объявила о принятии всех спецификаций LE Audio.

В работе участвовали более 25 рабочих групп, тысячи инженеров из сотен компаний, а от первоначальной концепции до завершения прошло около 7 лет. Это была не незначительная правка спецификации — это была переработка с нуля.

Думайте об этом так: классическое Bluetooth-аудио — это как стационарная телефонная система: надёжная, хорошо изученная, но принципиально ограниченная. LE Audio — это как переход на VoIP и стриминг: та же цель (передать аудио из точки A в точку B), но совершенно новая инфраструктура, открывающая возможности, которые старая система никогда не могла поддержать.

4. Кодек LC3: что это такое, битрейт и сравнение с LDAC/AAC

В основе LE Audio лежит новый обязательный кодек под названием LC3 — Low Complexity Communication Codec (кодек связи низкой сложности). Если SBC — это Honda Civic, то LC3 — Tesla Model 3. Он эффективнее, мощнее и создан с нуля для современной эпохи.

Что вообще такое кодек

Кодек (кодер/декодер) — это алгоритм, который сжимает аудио для передачи по беспроводному каналу с ограниченной полосой пропускания, а затем распаковывает его на другом конце. Чем лучше кодек, тем качественнее звучит аудио при заданном битрейте и тем меньше энергии расходуется на вычисления.

Технические характеристики LC3

LC3 был разработан компаниями Fraunhofer IIS (теми самыми, кто подарил нам MP3 и AAC — они знают толк в кодировании аудио) и Ericsson.

Ключевые характеристики:

• Частота дискретизации: 8, 16, 24, 32, 44,1 и 48 кГц
• Битовая глубина: 16, 24 или 32 бита
• Длительность фрейма: 7,5 мс и 10 мс
• Диапазон битрейта: от 16 до 320 кбит/с на канал
• Алгоритмическая задержка: 7,5 мс (для фреймов 7,5 мс) или 10 мс (для фреймов 10 мс)
• Каналы: моно или стерео

Почему LC3 лучше SBC

Главный тезис: LC3 обеспечивает эквивалентное или более высокое качество звука примерно при вдвое меньшем битрейте по сравнению с SBC.

В слуховых тестах, проведённых Fraunhofer, участники оценили LC3 при 160 кбит/с как эквивалентный или превосходящий SBC при 345 кбит/с. Это не незначительное улучшение — это почти двукратный прирост эффективности.

Этот прирост эффективности напрямую выражается в одном из двух результатов (или их комбинации):

• Лучшее качество звука при той же мощности — больше бит на качество, меньше потерь
• То же качество звука при меньшем энергопотреблении — устройство дольше работает от одного заряда

Как работает LC3 (упрощённая версия)

LC3 использует модифицированное дискретное косинусное преобразование (MDCT) — математический метод, который переводит аудио из временной области (форма волны) в частотную область (какие частоты присутствуют). Это похоже на то, что делают AAC и другие современные кодеки, однако преобразование LC3 оптимизировано для минимальной вычислительной сложности.

Упрощённый конвейер кодирования: входной PCM-сигнал проходит через MDCT для перевода из временной области в частотную. Затем применяется спектральное шумоподавление с использованием психоакустической модели для маскировки шума квантования в неслышимых частотных диапазонах, после чего выполняется квантование и энтропийное кодирование для получения сжатого битового потока LC3.

Ключевая идея — спектральное формирование шума: LC3 использует психоакустическую модель (модель восприятия звука человеком), чтобы шум квантования попадал в те частотные диапазоны, где он наименее заметен на слух. Ваши уши буквально не слышат искажений.

LC3 и LC3plus

Вы также можете встретить упоминание LC3plus — расширенной версии, которая добавляет:

• Режимы сверхширокой полосы и полной полосы (аудиополоса до 48 кГц)
• Дополнительные размеры фреймов (2,5 мс, 5 мс) для приложений со сверхнизкой задержкой
• Более высокое качество при очень низких битрейтах

LC3plus не входит в базовую спецификацию LE Audio, но используется в некоторых реализациях (например, DECT NR+ для беспроводных телефонов).

5. Изохронные каналы: новая инфраструктура

Здесь начинается архитектурно интересная часть. Классический Bluetooth-аудио использовал SCO-соединения (Synchronous Connection-Oriented, синхронно-ориентированные соединения) для голоса и L2CAP поверх ACL (Asynchronous Connection-Less, асинхронные бесподключённые каналы) для потоковой передачи через A2DP. Это работало, но напоминало использование садовых шлангов для разных целей — функционально, но не оптимизировано для аудио.

LE Audio вводит принципиально новый транспортный механизм на уровне канала связи: изохронные каналы. Это специально созданные каналы для передачи данных, чувствительных ко времени, — таких как аудио.

Что означает «изохронный»

«Изохронный» (от греч.: iso = равный, chronos = время) означает «происходящий через равные промежутки времени». Изохронный канал гарантирует, что данные поступают с предсказуемой, регулярной периодичностью — именно то, что нужно для аудио.

Представьте это так:

• Асинхронный (ACL): «Вот данные. Они дойдут, когда дойдут». Отлично для передачи файлов, плохо для аудио
• Синхронный (SCO): «Вот данные, которые ДОЛЖНЫ прийти вовремя, а если нет — ничего не поделаешь». Старые голосовые соединения, без повторных передач
• Изохронный: «Вот данные, которые должны прийти вовремя, и мы сделаем всё возможное с помощью умной повторной передачи». Лучшее из обоих миров

Два варианта: CIS и BIS

Изохронные каналы существуют в двух вариантах, и именно здесь происходит настоящая магия.

CIS (Connected Isochronous Stream, подключённый изохронный поток) предназначен для аудио точка-точка (unicast). Именно его использует телефон для потоковой передачи музыки на наушники.

Ключевые особенности CIS:

• Двунаправленность: аудио может передаваться в обоих направлениях одновременно — unicast к наушникам и аудио с микрофона обратно
• Подтверждение доставки: получатель отправляет подтверждения, что позволяет повторно передавать потерянные пакеты
• Группировка в CIG: несколько потоков CIS объединяются в CIG (Connected Isochronous Group, группа подключённых изохронных потоков), обеспечивая их синхронизацию

Последний пункт принципиально важен. CIG гарантирует, что левый и правый наушники получают аудиопакеты с точной синхронизацией — больше никаких ситуаций «левое ухо опережает правое на 50 мс».

BIS (Broadcast Isochronous Stream, широковещательный изохронный поток) предназначен для аудио один-ко-многим (broadcast). Это основа Auracast.

Ключевые особенности BIS:

• Однонаправленность: только в одну сторону — от источника к слушателям
• Без подтверждений: никаких ack от слушателей (источник даже не знает, кто слушает)
• Группировка в BIG: несколько потоков BIS образуют BIG (Broadcast Isochronous Group, группа широковещательных изохронных потоков)
• Масштабируемость: нет верхнего предела по числу слушателей — это настоящее радиовещание

Путь изохронных данных

Под капотом изохронные данные следуют по определённому пути через контроллер. Аудиофреймы от хоста проходят через HCI, затем через уровень адаптации ISO (ISO-AL, Isochronous Adaptation Layer), который обрабатывает сегментацию, добавление временны́х меток и управление таймаутом сброса, после чего достигают канального уровня для передачи по воздуху.

Ключевое нововведение — ISO-AL, расположенный между HCI и канальным уровнем. Он отвечает за:

• Сегментацию: разбиение аудиофреймов на части размером канального уровня
• Добавление временны́х меток: каждый аудиофрейм получает метку времени, чтобы получатель точно знал, когда его воспроизводить
• Таймаут сброса: если фрейм не может быть доставлен вовремя, он сбрасывается — лучше пропустить фрейм, чем воспроизвести его с опозданием

6. Стек профилей LE Audio: многоуровневый пирог из спецификаций

Если вы когда-нибудь смотрели на список спецификаций LE Audio и чувствовали, как взгляд начинает скользить по строчкам, — вы не одиноки. Их действительно очень много. Но они организованы в логическую иерархию, и как только понимаешь структуру, всё встаёт на свои места.

Представьте это как свадебный торт из трёх ярусов:

• Уровень 1 (фундамент): BAP, VCP, MCP, CCP, MICP, CSIP и BASS
• Уровень 2 (группирующий слой): CAP, который координирует профили уровня 1
• Уровень 3 (профили для конкретных сценариев использования): TMAP для телефонии и медиа, HAP для слуховых аппаратов и PBP для публичных трансляций

Уровень 1: Фундамент (базовые сервисы и профили)

Это строительные блоки, на которых строится всё остальное.

BAP (Basic Audio Profile, базовый аудиопрофиль) — главный из них. BAP определяет фундаментальные процедуры для обнаружения, настройки и установления потоков LE Audio. Он определяет две роли:

• Unicast Client: устройство, которое инициирует и управляет аудиопотоками (как правило, ваш телефон)
• Unicast Server: устройство, которое воспроизводит или захватывает аудио (как правило, ваши наушники)

BAP опирается на несколько GATT-сервисов:

• PACS (Published Audio Capabilities Service, сервис публикации аудиовозможностей): «Эй, вот какие аудиоформаты я поддерживаю»
• ASCS (Audio Stream Control Service, сервис управления аудиопотоком): «Давайте настроим аудиопотоки и будем ими управлять»

VCP (Volume Control Profile, профиль управления громкостью) обеспечивает удалённое управление громкостью. Телефон может управлять громкостью на наушниках (и наоборот) с помощью VCS (Volume Control Service).

MCP (Media Control Profile, профиль управления медиа) позволяет дистанционно управлять воспроизведением медиа. Пауза, воспроизведение, переключение треков и так далее — через MCS (Media Control Service). Аналог AVRCP для LE Audio.

CCP (Call Control Profile, профиль управления звонками) управляет состоянием телефонного звонка. Ответить, отклонить, поставить на удержание — через TBS (Telephone Bearer Service). Это заменяет функциональность управления звонками из HFP.

MICP (Microphone Control Profile, профиль управления микрофоном) обеспечивает удалённое включение и отключение микрофона устройства. Простая, но необходимая вещь — вы когда-нибудь были на звонке и не могли понять, как отключить микрофон? MICP это стандартизирует.

CSIP (Coordinated Set Identification Profile, профиль идентификации координированного набора) — это профиль «эти два наушника принадлежат друг другу». Он использует CSIS (Coordinated Set Identification Service), чтобы сообщить телефону: «Эй, я левый наушник, а мой приятель вон там — правый. Мы составляем пару». Без CSIP телефон воспринимал бы каждый наушник как полностью независимое устройство.

BASS (Broadcast Audio Scan Service, сервис сканирования широковещательного аудио) обеспечивает обнаружение источников широковещательного аудио. Устройство с BASS может сканировать ближайшие трансляции и помогать другому устройству (например, слуховым аппаратам) подключаться к ним.

Уровень 2: Группирующий слой

CAP (Common Audio Profile, общий аудиопрофиль) располагается поверх профилей уровня 1 и предоставляет общие процедуры, которые используют профили более высокого уровня. Он отвечает за такие задачи, как:

• Обнаружение координированного набора устройств (с использованием CSIP)
• Настройка unicast-аудиопотоков для координированного набора (с использованием BAP)
• Инициирование широковещательных аудиопотоков

Думайте о CAP как об «оркестраторе», который координирует совместную работу всех профилей уровня 1.

Уровень 3: Профили для конкретных сценариев использования

TMAP (Telephony and Media Audio Profile, профиль телефонии и медиааудио) — профиль «всё в одном» для типичных аудиосценариев. TMAP определяет такие роли, как:

• Call Terminal (CT): может совершать и принимать звонки
• Unicast Media Sender (UMS): может отправлять медиааудио (ваш телефон)
• Unicast Media Receiver (UMR): может принимать медиааудио (ваши наушники)
• Broadcast Media Sender (BMS): может транслировать медиааудио в широковещательном режиме
• Broadcast Media Receiver (BMR): может принимать широковещательное медиааудио

Если вы создаёте типичный сценарий «телефон + наушники», TMAP — это ваш профиль.

HAP (Hearing Access Profile, профиль доступа для слуховых аппаратов) — стандартизированный профиль для слуховых аппаратов. Он заменяет проприетарные решения MFi и ASHA официальным стандартом Bluetooth. HAP определяет процедуры для потоковой передачи аудио на слуховые аппараты, настройки пресетов и управления громкостью. Впервые слуховые аппараты могут взаимодействовать со всеми Bluetooth-устройствами с использованием стандартного протокола.

PBP (Public Broadcast Profile, профиль публичных трансляций) определяет, как настраивать и обнаруживать публичные трансляции (Auracast). Именно это обеспечивает сценарии «широковещательное аудио в терминале аэропорта».

7. Многопоточное аудио: больше никакой ретрансляции через левый наушник

Помните проблему ретрансляции в классическом Bluetooth? LE Audio полностью устраняет её с помощью многопоточного аудио.

С LE Audio исходное устройство (телефон) может отправлять независимые синхронизированные аудиопотоки напрямую в каждый наушник. Это принципиальное отличие от архитектуры ретрансляции: телефон отправляет независимые синхронизированные потоки напрямую в каждый наушник через отдельные каналы CIS в рамках CIG, что обеспечивает равномерный расход заряда батареи и меньшую задержку.

Как это работает

1. Оба наушника независимо подключаются к телефону через BLE
2. Телефон идентифицирует их как координированный набор с помощью CSIP
3. Телефон устанавливает CIG с двумя потоками CIS — по одному на каждый наушник
4. Телефон отправляет левый канал по CIS №1, а правый канал — по CIS №2
5. CIG обеспечивает синхронизацию обоих потоков — наушники воспроизводят свои соответствующие каналы в точно одинаковое время

Преимущества:

• Равномерный расход заряда батареи: оба наушника выполняют одинаковый объём работы
• Меньшая задержка: отсутствие промежуточного ретрансляционного прыжка означает меньше задержек
• Лучшая надёжность: если один наушник теряет соединение, второй продолжает воспроизведение
• Настоящее стерео: каждый наушник получает собственный независимый поток, нет необходимости декодировать и разделять сигнал

8. Auracast: что это такое и как работает широковещательное аудио

Auracast — это функция широковещательной передачи LE Audio, и она, пожалуй, является наиболее революционной его частью. Это как FM-радио для Bluetooth: один источник, неограниченное количество слушателей.

Как работает Auracast

1. Broadcast Source (источник трансляции) создаёт BIG, содержащую один или несколько потоков BIS
2. Источник анонсирует трансляцию с помощью Extended Advertising (расширенной рекламы) с метаданными (название потока, язык, конфигурация кодека)
3. Broadcast Sink (приёмник трансляции) обнаруживает анонс, синхронизируется с поездом Periodic Advertising для получения параметров потока
4. Приёмник присоединяется к BIG и начинает получать аудио

Сценарии использования Auracast

Сценарии использования действительно впечатляют:

• Аэропорты/вокзалы: трансляция объявлений у выхода на посадку напрямую в наушники пассажиров — на нескольких языках
• Спортзалы: каждый телевизор на стене может транслировать собственное аудио — выбирайте, какой слушать
• Музеи: аудиогиды транслируются в собственные наушники посетителей
• Бары/спортивные мероприятия: смотрите игру на большом экране с комментарием в наушниках, не мешая окружающим
• Конференции: каналы синхронного перевода транслируются участникам
• Тихие дискотеки: очевидно

Роль BASS: Broadcast Assistants

Существует интересная вспомогательная концепция под названием Broadcast Assistant (помощник трансляции). Это устройство (как правило, телефон), которое помогает другому устройству (как правило, наушникам) обнаруживать трансляции и подключаться к ним.

Зачем? Потому что крошечные наушники могут не иметь достаточной вычислительной мощности или пользовательского интерфейса для самостоятельного сканирования и выбора трансляций. Поэтому телефон выполняет сканирование, показывает доступные трансляции и сообщает наушникам, к какой из них подключиться, — через BASS.

9. Bluetooth LE Audio в Android/AOSP: реализация и включение

Теперь перейдём к коду. Здесь теория встречается с практикой.

Хронология поддержки LE Audio в Android

• Android 12 (2021): введены первоначальные API для LE Audio (качество предварительной версии для разработчиков)
• Android 13 (2022): полная поддержка LE Audio, включая unicast client/server, broadcast source/sink
• Android 14 (2023): улучшенная стабильность, улучшения broadcast audio, поддержка роли LE Audio source
• Android 15 (2024): поддержка Auracast Broadcast Sink, роль Broadcast Assistant, улучшенное переключение аудиоконтекста
• Android 16 (2025): нативный интерфейс Auracast в быстрых настройках/настройках Bluetooth, улучшенный опыт совместного использования аудио

Реализация LE Audio в AOSP находится преимущественно в модуле Bluetooth (packages/modules/Bluetooth), который является модулем Mainline — то есть может обновляться через Google Play System Updates независимо от полных обновлений ОС Android.

Ключевые расположения исходников в AOSP

Если вы хотите самостоятельно погрузиться в код, вот ваша карта сокровищ:

Компонент	Путь
Нативный стек (C++)	packages/modules/Bluetooth/system/btif/src/

Высокоуровневая архитектура

Стек Bluetooth в AOSP для LE Audio следует классической многоуровневой архитектуре Android. Сверху вниз: слой приложений, Framework APIs (BluetoothLeAudio, BluetoothLeBroadcast), LeAudioService (Java), JNI Bridge, нативный стек C++ (le_audio_client, codec_manager, state_machine, iso_manager), слой HCI и аппаратный контроллер Bluetooth.

10. Архитектура AOSP: от приложения до антенны

Рассмотрим каждый уровень подробно.

Уровень 1: Framework APIs

Android предоставляет функциональность LE Audio через несколько публичных классов API в android.bluetooth.

BluetoothLeAudio — основной API для unicast LE Audio. Приложения используют его для подключения к устройствам LE Audio, установки активного устройства для воспроизведения/захвата аудио, запроса информации о группах (координированные наборы) и выбора конфигурации кодека:

// Пример: подключение к устройству LE Audio
BluetoothLeAudio leAudio = bluetoothAdapter.getProfileProxy( context, listener, BluetoothProfile.LE_AUDIO);

// Установка устройства LE Audio как активного для воспроизведения медиа
leAudio.setActiveDevice(leAudioDevice);

BluetoothLeBroadcast — API для широковещательного аудио (Auracast). Приложения используют его для запуска/остановки широковещательного аудио, установки метаданных трансляции (название, язык) и настройки кода трансляции (пароль шифрования):

// Запуск трансляции
BluetoothLeBroadcast broadcast = bluetoothAdapter.getProfileProxy( context, listener, BluetoothProfile.LE_AUDIO_BROADCAST);
broadcast.startBroadcast(contentMetadata, audioConfig, broadcastCode);

BluetoothLeBroadcastAssistant — API для роли broadcast assistant, помогающей другому устройству настроиться на трансляцию.

BluetoothVolumeControl — API для удалённого управления громкостью через VCP.

BluetoothHapClient — API для профиля Hearing Access Profile, управляющего пресетами слуховых аппаратов и потоковой передачей.

Уровень 2: LeAudioService (мозг)

LeAudioService — это центральный сервис внутри приложения Bluetooth, который оркестрирует всю функциональность LE Audio. Именно здесь происходит волшебство.

Ключевые обязанности:

• Управление устройствами: отслеживание подключённых устройств LE Audio и их возможностей
• Управление группами: управление координированными наборами (какие устройства принадлежат вместе)
• Маршрутизация аудио: определение того, какое устройство (или устройства) должно быть активным для воспроизведения/захвата
• Управление конечными автоматами: обработка жизненного цикла аудиосоединений
• Координация профилей: координация BAP, VCP, MCP, CCP и CSIP

Уровень 3: Нативный стек (C++)

Ниже уровня Java основная работа выполняется на C++. Нативная реализация LE Audio находится в стеке Bluetooth (исторически называемом «Fluoride», с более новыми компонентами в «Gabeldorsche»).

Ключевые нативные компоненты:

le_audio_client_impl — основная реализация клиента LE Audio на C++. Обрабатывает операции клиента GATT (обнаружение сервисов, чтение характеристик), управление конечным автоматом ASE (Audio Stream Endpoint, конечная точка аудиопотока), согласование кодека с удалёнными устройствами, создание и управление CIS/BIS.

LeAudioStateMachine управляет конечным автоматом состояния соединения для каждого устройства LE Audio с состояниями: Disconnected, Connecting, Connected и Disconnecting. Конечный автомат управляет настройкой GATT-соединения, обнаружением сервисов и чтением характеристик перед переходом в состояние Connected.

codec_manager обрабатывает конфигурацию кодека: перечисляет поддерживаемые возможности кодека, выбирает оптимальную конфигурацию на основе возможностей устройства и варианта использования, взаимодействует с кодировщиком/декодировщиком LC3.

iso_manager управляет изохронными каналами: создаёт и разрывает CIG/CIS для unicast, создаёт и разрывает BIG/BIS для broadcast, обрабатывает HCI-интерфейс для изохронных данных.

bluetooth_audio_hal_interface связывает стек Bluetooth с Android audio HAL: получает PCM-аудио от аудиофреймворка Android, передаёт его кодировщику LC3, отправляет закодированное аудио по изохронным каналам.

Уровень 4: Контроллер (аппаратное обеспечение)

Контроллер Bluetooth обрабатывает низкоуровневые радиооперации: планирование изохронных событий на канальном уровне, физический уровень (1M, 2M или Coded PHY), форматирование пакетов и CRC, повторную передачу потерянных изохронных PDU.

Хост (Android) взаимодействует с контроллером через HCI (Host Controller Interface, интерфейс хост-контроллера), используя специфические HCI-команды для изохронных каналов:

• HCI_LE_Set_CIG_Parameters — настройка Connected Isochronous Group
• HCI_LE_Create_CIS — создание Connected Isochronous Streams
• HCI_LE_Create_BIG — создание Broadcast Isochronous Group
• HCI_LE_Setup_ISO_Data_Path — настройка пути для ISO-данных (HCI или вендорно-специфический)
• HCI_LE_BIG_Create_Sync — синхронизация с BIG (для приёмников broadcast)

11. Реализация на стороне сервера (источника)

«Серверная сторона» в терминологии LE Audio — это фактически Unicast Server, устройство, которое воспроизводит звук (ваши наушники). Да, это сбивает с толку: получатель называется «сервером». Думайте об этом как о GATT-сервере: он хостит GATT-сервисы, к которым подключается клиент.

Что делает Unicast Server

Unicast Server (наушники) хостит несколько GATT-сервисов:

• PACS — объявляет поддерживаемые устройством кодеки, частоты дискретизации, длительности фреймов и аудиоконтексты
• ASCS — содержит одну или несколько характеристик ASE, в которые клиент выполняет запись для настройки и управления аудиопотоками
• VCS — позволяет клиенту читать и устанавливать уровень громкости устройства
• CSIS — идентифицирует данное устройство как часть скоординированного набора (например, «я левый наушник, а мой партнёр — правый наушник»)

Unicast Client (телефон) подключается к этим сервисам через GATT для обнаружения возможностей, настройки потоков и управления воспроизведением.

Конечный автомат ASE (на стороне сервера)

Каждый ASE на сервере имеет конечный автомат. Это сердце управления аудиопотоками. Состояния: Idle, Codec Configured, QoS Configured, Enabling, Streaming, Disabling и Releasing. Клиент управляет переходами, записывая операции (Config Codec, Config QoS, Enable, Disable, Release) в характеристику ASE Control Point.

Переходы между состояниями:

• IDLE → CODEC_CONFIGURED: клиент записывает операцию Config Codec в ASE Control Point, указывая тип кодека (LC3), частоту дискретизации, длительность фрейма и так далее
• CODEC_CONFIGURED → QoS_CONFIGURED: клиент записывает операцию Config QoS, указывая интервал SDU, фреймирование (framed или unframed), максимальный размер SDU, число повторных передач, максимальную транспортную задержку и задержку представления
• QoS_CONFIGURED → ENABLING: клиент записывает операцию Enable; сервер готовится к приёму аудио
• ENABLING → STREAMING: устанавливается CIS и начинается передача аудиоданных; этот переход происходит после того, как клиент создаёт CIS и обе стороны готовы
• STREAMING → DISABLING: клиент записывает операцию Disable, или соединение разрывается
• Любое состояние → IDLE: клиент записывает операцию Release, разрушая конфигурацию потока

Стандартные конфигурации кодека

BAP определяет набор именованных конфигураций кодека, которые соответствуют конкретным параметрам LC3. Это «пресеты», которые согласовывают устройства:

Конфигурация	Частота дискретизации	Длительность фрейма	Битрейт
8_1	8 кГц	7,5 мс	26 кбит/с
8_2	8 кГц	10 мс	24 кбит/с
16_1	16 кГц	7,5 мс	32 кбит/с
16_2	16 кГц	10 мс	32 кбит/с
24_2	24 кГц	10 мс	48 кбит/с
32_2	32 кГц	10 мс	64 кбит/с
48_1	48 кГц	7,5 мс	75 кбит/с
48_4	48 кГц	10 мс	96 кбит/с

Для большинства потребительских наушников вы увидите 48_4 (96 кбит/с при 48 кГц) для медиа и 16_2 (32 кбит/с при 16 кГц) для телефонных звонков. Единственный кодек LC3 обрабатывает оба сценария использования — больше никакого переключения между SBC и mSBC.

Типы аудиоконтекстов

LE Audio определяет типы аудиоконтекстов (Audio Context Types) — метаданные, которые сообщают принимающему устройству, какой тип аудио передаётся. Это позволяет устройству оптимизировать своё поведение:

Контекст	Описание
Prohibited	Не используется
Unspecified	Общий аудиоконтекст
Conversational	Голосовые звонки
Media	Музыка, подкасты
Game	Игровое аудио (низкая задержка)
Instructional	Голосовые подсказки
VoiceAssistants	Голосовые ассистенты
Live	Живые события
SoundEffects	Звуковые эффекты
Notifications	Уведомления
Ringtone	Рингтоны
Alerts	Сигналы тревоги
EmergencyAlarm	Экстренные сигналы

Это значительно более детально, чем Classic Audio, который по сути знал только два состояния: «вы воспроизводите музыку» (A2DP) или «вы на звонке» (HFP). С LE Audio устройство может принимать интеллектуальные решения, например: «это игра, используй фреймы 7,5 мс для минимальной задержки» или «это уведомление, подмешай его, не прерывая музыкальный поток».

Реализация Unicast Server в AOSP

В AOSP функциональность Unicast Server реализована прежде всего для случаев, когда устройство Android выступает в роли получателя (например, слуховой аппарат на базе Android или Chromebook, принимающий аудио).

Ключевые классы:

• LeAudioService.java — обрабатывает операции на стороне сервера, когда устройство находится в роли sink
• В нативном коде: le_audio_server.cc управляет GATT-сервером, хостирующим PACS, ASCS и так далее

Реализация Broadcast Source

Для широковещательного аудио (Auracast) исходная сторона в AOSP включает:

// В LeAudioService.java / BroadcastService
public void startBroadcast(BluetoothLeBroadcastSettings settings) { // 1. Настроить LC3-энкодер с параметрами широковещания // 2. Настроить Extended Advertising с метаданными широковещания // 3. Настроить Periodic Advertising для параметров потока // 4. Создать BIG через HCI // 5. Начать отправку ISO-данных по потокам BIS
}

Нативная реализация:

• broadcaster.cc / broadcaster_impl — управляет жизненным циклом широковещания
• Настраивает Extended Advertising с именем и метаданными широковещания
• Настраивает Periodic Advertising для передачи структуры данных BASE (Broadcast Audio Source Endpoint, конечная точка источника широковещательного аудио)
• Создаёт BIG с соответствующим числом потоков BIS
• Направляет закодированное аудио в путь данных BIS

12. Реализация на стороне клиента (Sink)

«Клиентская сторона» — это Unicast Client, как правило, ваш телефон. Он обнаруживает LE Audio-устройства, подключается к ним и управляет ими.

Поток подключения

Вот что происходит при подключении к LE Audio-наушникам, шаг за шагом:

1. BLE-сканирование и обнаружение
2. GATT-подключение
3. Обнаружение сервисов (поиск PACS, ASCS, CSIP, VCS)
4. Чтение PAC-записей для получения информации об аудиовозможностях
5. Чтение CSIS для определения членства в координированном наборе
6. Конфигурация ASE (Config Codec, Config QoS, Enable)
7. Создание CIS и аудиостриминг

Реализация клиента в AOSP подробно

// LeAudioService.java
public void connect(BluetoothDevice device) { // Создаёт новый LeAudioStateMachine для данного устройства LeAudioStateMachine sm = getOrCreateStateMachine(device); sm.sendMessage(LeAudioStateMachine.CONNECT); // Конечный автомат обрабатывает: // - GATT-подключение // - Обнаружение сервисов // - Чтение характеристик
}

LeAudioStateMachine управляет жизненным циклом подключения:

// LeAudioStateMachine.java (упрощённо)
class LeAudioStateMachine extends StateMachine { class Disconnected extends State { void processMessage(Message msg) { if (msg.what == CONNECT) { // Инициировать GATT-подключение через native mNativeInterface.connectLeAudio(mDevice); transitionTo(mConnecting); } } } class Connecting extends State { void processMessage(Message msg) { if (msg.what == CONNECTION_STATE_CHANGED) { if (newState == CONNECTED) { transitionTo(mConnected); } } } } class Connected extends State { void enter() { // GATT-сервисы обнаружены // Аудиовозможности прочитаны // Устройство готово к стримингу broadcastConnectionState(BluetoothProfile.STATE_CONNECTED); } }
}

Нативный слой читает PACS, чтобы понять, что поддерживает удалённое устройство:

// В native le_audio_client_impl (C++)
void OnGattServiceDiscovery(BluetoothDevice device) { // Читать PAC-записи из PACS ReadPacsCharacteristics(device); // Читать CSIS для информации о координированном наборе ReadCsisCharacteristics(device); // Читать ASCS для количества и состояния ASE ReadAscsCharacteristics(device);
}

void OnPacsRead(BluetoothDevice device, PacRecord sink_pac) { // sink_pac содержит: // codec_id: LC3 // sampling_frequencies: 48000, 44100, 32000, 24000, 16000, 8000 // frame_durations: 10ms, 7.5ms // channel_counts: 1 // octets_per_frame: 40-155 (соответствует диапазону битрейта) // supported_contexts: MEDIA, CONVERSATIONAL, GAME // Сохранить возможности для последующего согласования кодека device_info.sink_capabilities = sink_pac;
}

При начале воспроизведения аудио клиент конфигурирует и включает потоки:

// В native codec_manager (C++)
CodecConfig SelectCodecConfiguration( PacRecord remote_capabilities, AudioContext context // MEDIA, CONVERSATIONAL и т.д.
) { // Для воспроизведения медиа предпочтительно высокое качество: // 48 кГц, кадры 10 мс, 96 кбит/с на канал // Для голосовых вызовов оптимизация по задержке: // 16 кГц, кадры 7,5 мс, 32 кбит/с на канал // Согласование: пересечение локальных и удалённых возможностей // Выбор наилучшей конфигурации, поддерживаемой обеими сторонами
}

// В native le_audio_client_impl
void GroupStreamStart(int group_id, AudioContext context) { auto group = GetGroup(group_id); auto codec_config = SelectCodecConfiguration( group->GetRemoteCapabilities(), context);

// Для каждого устройства в группе: for (auto& device : group->GetDevices()) { // Для каждого ASE на устройстве: for (auto& ase : device->GetAses()) { // Шаг 8: Config Codec WriteAseControlPoint(device, OPCODE_CONFIG_CODEC, { .ase_id = ase->id, .codec_id = LC3, .codec_specific = { .sampling_freq = 48000, .frame_duration = 10ms, .channel_allocation = LEFT, // или RIGHT .octets_per_frame = 120 } }); } } // После уведомления о конфигурации кодека: // Шаг 9: Config QoS → Шаг 10: Enable → Шаг 11: Create CIS
}

После начала стриминга аудиоданные проходят через стек AOSP следующим образом: PCM-аудио из аудиофреймворка Android поступает в Bluetooth Audio HAL, кодируется кодировщиком LC3, упаковывается в ISO SDU с временными метками, отправляется через HCI на контроллер, передаётся по воздуху через CIS, принимается контроллером наушника, декодируется декодером LC3 наушника и воспроизводится как аудио.

Реализация Broadcast Sink

Для приёма широковещательного аудио (Auracast) в AOSP реализовано сканирование Extended Advertising для обнаружения трансляций, синхронизация с Periodic Advertising для получения параметров BIG, создание синхронизации BIG через HCI_LE_BIG_Create_Sync и приём ISO-данных из потоков BIS.

13. Конечный автомат, управляющий всем

Реализация LE Audio в AOSP использует несколько взаимосвязанных конечных автоматов.

Конечный автомат состояния подключения

Управляет общим жизненным циклом подключения для каждого устройства. Четыре состояния: Disconnected (отключено), Connecting (подключение), Connected (подключено) и Disconnecting (отключение).

Переходы: событие CONNECT переводит из Disconnected в Connecting, успешное подключение — в Connected, событие DISCONNECT — в Disconnecting, а завершение возвращает в Disconnected. Таймаут или сбой из Connecting также возвращает в Disconnected.

Конечный автомат аудиосостояния группы

Управляет аудиосостоянием группы устройств (координированного набора). Состояния: Idle (ожидание), Codec Configured (кодек настроен), QoS Configured (QoS настроен), Enabling (включение), Streaming (стриминг) и Disabling (отключение). Прямой путь проходит через каждое состояние по порядку по мере настройки аудиопотоков. Операция Release возвращает любое состояние в Idle.

Как всё складывается вместе (разбор кода)

Вот что происходит, когда вы нажимаете «воспроизвести» в музыкальном приложении при подключённых LE Audio-наушниках:

1. Музыкальное приложение записывает PCM-аудио в AudioTrack
2. Android AudioFlinger направляет аудио в Bluetooth Audio HAL
3. HAL уведомляет LeAudioService о начале воспроизведения аудио
4. LeAudioService находит активную группу и запускает GroupStreamStart в нативном стеке
5. Нативный стек конфигурирует ASE на обоих наушниках (Config Codec → Config QoS → Enable), записывая в контрольную точку ASCS на каждом устройстве
6. Нативный стек создаёт CIG с двумя CIS-каналами через HCI
7. Оба CIS-канала устанавливаются к наушникам
8. Настраивается путь передачи данных ISO
9. PCM-аудио поступает из HAL в кодировщик LC3, который создаёт сжатые кадры
10. Сжатые кадры отправляются как ISO SDU через HCI на контроллер
11. Контроллер передаёт кадры по воздуху в запланированные интервалы CIS
12. Наушники принимают, декодируют и воспроизводят аудио с согласованной задержкой представления

14. Всё вместе: один день из жизни LE Audio-пакета

Давайте проследим за одним аудиопакетом от музыкального приложения до наушника.

Музыкальное приложение генерирует PCM-аудио, которое проходит через Android AudioFlinger в Bluetooth Audio HAL. HAL передаёт 10 мс PCM-сэмплов (480 сэмплов при 48 кГц) в кодировщик LC3, который сжимает их в кадр размером ~120 байт.

Этот кадр оборачивается в ISO SDU с временной меткой и порядковым номером, затем передаётся через HCI на Bluetooth-контроллер. Контроллер сегментирует SDU на PDU канального уровня, планирует их на следующее событие CIS и передаёт по воздуху с использованием согласованного PHY (например, 2M PHY).

На стороне наушника контроллер принимает PDU, собирает ISO SDU и передаёт кадр LC3 декодеру наушника. Декодер восстанавливает 480 PCM-сэмплов, которые буферизируются до достижения временной метки задержки представления, а затем воспроизводятся через драйвер динамика.

Общая задержка: ~40 мс от телефона до наушника (с кадром 10 мс + транспортная задержка + задержка представления). Для сравнения: Classic Bluetooth A2DP обычно работает с задержкой 100–200 мс.

Задержка представления: секрет синхронизации

Задержка представления — ключевая концепция LE Audio. Это фиксированная задержка, о которой обе стороны договариваются в процессе настройки потока. Всё аудио должно воспроизводиться ровно в момент:

rendering_time = reference_anchor_point + presentation_delay

Это обеспечивает воспроизведение аудио левым и правым наушниками в один и тот же момент времени — даже если транспортная задержка между двумя CIS-каналами различается. Задержка представления создаёт «буфер», позволяющий получателю поглощать джиттер.

Думайте об этом как о дирижёре хора: «Все поют на счёт три. Не раньше, не позже. Ровно на три».

15. Подведение итогов

Bluetooth LE Audio — это самое значительное обновление Bluetooth-аудио с момента изобретения Bluetooth-аудио как такового. Я намеренно разобрал каждый уровень стека, потому что понять LE Audio по-настоящему можно только видя, как все части работают вместе — от психоакустики LC3 до HCI-команд контроллера.

Что это решает:

• Лучший кодек (LC3) — эквивалентное качество при вдвое меньшем битрейте по сравнению с SBC
• Единый кодек для всех сценариев — больше никакого переключения между SBC и mSBC при звонках
• Нативное многопоточное аудио — конец эпохи ретрансляции через основной наушник
• Изохронные каналы — транспорт, созданный специально для аудио, с гарантиями по времени
• Auracast — настоящее широковещательное аудио без ограничений по числу слушателей
• HAP — официальный стандарт для слуховых аппаратов вместо проприетарных решений
• Меньшее энергопотребление — BLE вместо BR/EDR как основа всего стека

Реализация в AOSP отражает эту сложность: многоуровневая архитектура от Framework API через LeAudioService и нативный C++-стек до контроллера, с несколькими взаимосвязанными конечными автоматами, управляющими жизненным циклом каждого соединения и каждого аудиопотока.

Ответы на эти вопросы могут быть для вас полезными

Почему звонок через Bluetooth-наушники звучит хуже, чем музыка?

В классическом Bluetooth это происходит из-за переключения между профилями: музыка идёт через A2DP с кодеком SBC или AAC, а звонок — через HFP с кодеком CVSD или mSBC, который работает на значительно более низком битрейте. LE Audio решает эту проблему: единственный кодек LC3 обрабатывает оба сценария, просто с разными конфигурациями (48_4 для медиа, 16_2 для звонков).

Почему один наушник из пары разряжается быстрее другого?

Это прямое следствие архитектуры ретрансляции в классическом Bluetooth. Основной наушник (обычно правый) принимает стереопоток от телефона и ретранслирует второй канал на вторичный наушник, выполняя двойной объём работы. LE Audio устраняет эту проблему: телефон отправляет независимые потоки напрямую в каждый наушник через отдельные CIS-каналы в рамках одной CIG.

Что такое Auracast и чем он отличается от обычного Bluetooth-аудио?

Auracast — это широковещательный режим LE Audio, основанный на BIS (Broadcast Isochronous Stream). В отличие от обычного unicast-аудио (один источник, один приёмник), Auracast работает по схеме один-ко-многим: источник транслирует аудио, а любое количество устройств может принимать его без установки соединения с источником — аналогично FM-радио. Типичные сценарии: объявления в аэропортах, аудиогиды в музеях, тихие дискотеки.

Начиная с какой версии Android поддерживается LE Audio?

Базовая поддержка появилась в Android 12 (2021) в виде предварительных API для разработчиков. Полноценная поддержка unicast и broadcast — в Android 13 (2022). Поддержка Auracast Broadcast Sink и роли Broadcast Assistant добавлена в Android 15 (2024). Нативный интерфейс Auracast в быстрых настройках появился в Android 16 (2025).

Как LE Audio синхронизирует левый и правый наушники?

Через механизм задержки представления (presentation delay). В процессе настройки потока обе стороны договариваются о фиксированной задержке, и каждый аудиофрейм получает временну́ю метку. Наушники буферизируют полученные фреймы и воспроизводят их строго в момент reference_anchor_point + presentation_delay — это гарантирует синхронное воспроизведение даже при различной транспортной задержке между двумя CIS-каналами.