Обзоры и статьи - Обзор. Беспроводной звук -аудиосистемы

2016-10-17 00:00:00

Обзор. Беспроводной звук -аудиосистемы

Беспроводной звук. Препарируем Bluetooth (часть 1 )
Обзор Edifier Spinnaker- беспроводная стерео-система Bluetooth (часть 2 )

Иногда, бывает, натыкаешься на какой-то баг впервые, списываешь все на обстоятельства и забываешь о нем. Затем он повторяется снова и снова, вынуждая тебя приступить к поиску проблем и, по возможности, их устранению. И вот когда ты обнаруживаешь себя в глубокой ночи за анализом дампом/дебагом/чтением_мануалов, то становится понятно, дело на полпути бросать уже нельзя и дело принципа — довести его до конца.

Такая история со мной приключилась в момент обзора с коллегой r3s потребительской беспроводной www.bluetooth.com/Pages/Bluetooth-Home.aspx Bluetooth-акустики Klipsch KMC 3. Я столкнулся с ситуацией, когда «беспроводной» аудиопоток начинал безбожно прерываться, стоило лишь мне расположить источник звука у себя за спиной. Пищи для размышлений мне подкинула другая Bluetooth-аудиосистема, которая в тех же условиях вела себя куда лучше. Такая простая проблема выродилась в нырок с головой во внутренности протокола Bluetooth и детали передачи аудио с его помощью.

Под катом первой части цикла статей мы в легкой и непринужденной форме познакомимся с основными протоколами стека Bluetooth, покопаемся в дампе соединения источника и приемника звука, разберемся в причинах конфликта Bluetooth и Wi-Fi и обнаружим корень моей проблемы — прерывающегося звука.

Беспроводной звук. Препарируем Bluetooth

Оставим за кадром (или перенесем в комментарии) полемику на тему “зачем нам беспроводная передача аудио, если можно обойтись православными проводными решениями, сэкономив кучу денег и выиграв в качестве”. Условимся, что беспроводной стриминг аудио с любых устройств, как портативных, так и не очень, нам интересен, ведь с ним мы можем:

1. Проигрывать аудио с мобильных устройств (Google Music + iTunes Match = вся медиатека в облаке и доступна с любого устройства) на беспроводные аудиосистемы и ресиверы. Не будем забывать, что именно телефоны сейчас завоевывают пальму первенства среди носителей музыкальных треков пользователей;

2. Озвучивать пространства, в которых установка проводных решений по ряду причин затруднена (кухня, террасы, балконы, outdoor-зоны вашего загородного поместья);

3. Позволять гостям “ставить их компакт-диск”;

Забыть о кредлах, т.к. расставание с телефоном для многих становится мучительным процессом.

Таким образом, на момент чтения этой статьи забываем о холиваре wired vs wireless и окунаемся в мир беспроводных технологий, в которых, как оказалось, есть много интересных деталей, стоит только копнуть глубже.

Беспроводной звук. Препарируем Bluetooth

King Bluetooth

Виновница торжества — технология Bluetooth, получившая жизнь благодаря инициативе Ericsson в далеком 1994 году, затем стандартизованная IEEE (802.15-1) и по настоящее время развиваемая целой группой по интересам www.bluetooth.org/en-us Bluetooth Special Interest Group (SIG). На текущий момент альянс Bluetooth SIG насчитывает порядка 18 000 компаний, среди которых, естественно, есть и те, кто занимается производством аудио компонентов, способных принимать без проводов стерео сигнал.

Недавно я обзавелся одним из таких устройств. Cистема Klipsch KMC 3, обзор которой есть на Хабре, удовлетворяла всем, кроме одного: при определенных условиях начинала воспроизводить звук, ужасно прерываясь. Юзкейс был следующим: в качестве источника аудиосигнала выступал Macbook Air 2012, и стоило расположить его за собственным телом в 4 метрах от системы (читай “сесть спиной к колонке с ноутбуком на коленях), как звук начинал прерываться. Второй участник Bluetooth-состязания (обзор которого вас ждет в конце поста) — Edifier Spinnaker E30, тоже страдал замиранием сигнала, но при этом в куда меньшей степени. Возник вопрос, в чем могла крыться причина столь разного поведения двух систем в одинаковых условиях?

Налицо проблема с распространением сигнала, но стоило в тех же условиях воспользоваться мобильным телефоном для воспроизведения аудио, как проблема становилась куда менее заметной. Так было решено разобраться в причинах и следствиях, что и привело меня к самым истокам — чтению Bluetooth Core Specification, анализу дампов сетевого соединения и модификации важных для аудиокодеков значений. Для начала, впрочем, требовалось исключить возможность интерференции между Bluetooth и Wi-Fi.

Одна кухня и несколько поваров

Не секрет, что и Bluetooth, и Wi-Fi (и еще множество систем) работают в одном диапазоне частот — ISM диапазоне — в границах 2.400 GHz — 2.4835 GHz. Использование одного частотного диапазона для передачи информации разных систем неминуемо приведет к интерференции сигналов, а значит — к потере данных. Именно на интерференцию сигналов Wi-Fi и Bluetooth я изначально и грешил.

Модуляция

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

Стандарт 802.11n (а я верю, что у 90% пользователей Хабра дома развернут именно он, хотя все нижеизложенное справедливо и для 11g) предусматривает использование OFDM модуляции сигнала с организацией 13 каналов шириной 20 МГц.

Беспроводной звук. Препарируем Bluetooth

При этом стандартом 802.11b/g/n предусмотрено использование одного канала на протяжении всего времени работы, если его состояние считается удовлетворительным (читай “нет чередования каналов”).

Bluetooth же использует иной подход: в спектре ISM организуется 79 каналов шириной в 1 МГц, а затем по технологии расширения спектра Frequency-hopping Spread Spectrum (FHSS) радиоприемник и радиопередатчик синхронно меняют частоту несущей по определенному шаблону с частотой 1600 раз в секунду. Сделано это как раз для уменьшения вероятности наложения сигналов в крохотном ISM диапазоне.

Беспроводной звук. Препарируем Bluetooth

Если бы у вас дома был спектральный анализатор, то процесс смены несущей по всему 2.4ГГц диапазону выглядел бы следующим образом:

Беспроводной звук. Препарируем Bluetooth

Случайным образом разбросанные красные точки — это и есть сигнал Bluetooth, постоянно меняющий частоту. Зеленые области — это три активных канала Wi-Fi.

Борьба с интерференцией.

Однако техника скоростной смены несущей не избавляет от интерференции, а всего лишь снижает вероятность ее возникновения. Шансы у Bluetooth-сигнала попасть в 20 МГц диапазон канала Wi-Fi по-прежнему ненулевые:

Беспроводной звук. Препарируем Bluetooth

Поэтому в арсенале стека Bluetooth есть технология адаптивной смены частоты — www.design-reuse.com/articles/5715/adaptive-frequency-hopping-for-reduced-interference-between-bluetooth-and-wireless-lan.html Adaptive Frequency Hopping (AFH). Принцип работы AFH состоит в следующем: из 79 доступных 1 МГц каналов исключаются каналы, попадающие в занятый Wi-Fi сигналом диапазон:

Беспроводной звук. Препарируем Bluetooth

На рисунке выше видно, как алгоритм AFH скорректировал карту доступных для “перескакивания” каналов, исключив те, что попали в уже занятый вайфаем 6-й канал.

Но мне не повезло, дело было не в интерференции сигнала, т.к. я перенес WLAN в “безопасный” для Bluetooth диапазон 5 ГГц (это, кстати, самый действенный метод для исключения возможных проблем), а прерывания аудио так никуда и не исчезли. Пришлось копать глубже.

Беспроводной звук. Препарируем Bluetooth

Разбор дампа Bluetooth.

Раз проблема была не в интерференции с Wi-Fi, то потребовалось более глубокое погружение в матчасть. Напомню, что интересным с точки зрения анализа был тот факт, что в одинаковых условиях две Bluetooth аудиосистемы (Klipsch KMC 3 и Edifier Spinnaker) вели себя по-разному. Klipsch захлебывался раньше, и для достижения эффекта нужно было просто заслонить телом прямой путь к колонке на расстоянии нескольких метров. Edifier же мог хрюкнуть пару раз, но после продолжал уверенно воспроизводить звук, изредка прерываясь.

Симптомы косвенно намекали на автоподстройку неких параметров со стороны Эдифаеров и отсутствие оной у Клипша при деградации качества радиосигнала. Чтобы проверить эту теорию, было решено снять дамп соединения двух устройств с целью поиска источника проблем.

Для чистоты эксперимента я выключил модуль Bluetooth, удалил из списка сопряженных устройств Klipsch, включил “синий зуб”, и, нажав кнопку записи дампа, прошел процедуру от поиска устройства и соединения с ним до передачи аудио.

Инициализация устройства

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

Происходит это в форме диалога HCI Command -> HCI Event.

Беспроводной звук. Препарируем Bluetooth

Стек блютуса лишь косвенно напоминает привычный TCP/IP, поэтому лицезрение дампа без предварительного прочтения спецификации не увенчалось успехом.

К чести группы Bluetooth SIG отмечу, что документация на корневую спецификацию и всевозможные профили находится в свободном доступе на портале для разработчиков, при этом написана простым и понятным языком.

Архитектура Bluetooth

Так моей настольной книгой на энное количество времени стала Bluetooth Core Specification. 13 мегабайтная пдф-ка о шести томах только сперва кажется необъятной, но для понимания базовых операций и принципов взаимодействия подсистем достаточно будет и нескольких глав.

Беспроводной звук. Препарируем Bluetooth

Core System

В процессе поиска источника проблем я шел сверху вниз: встречая в дампе высокоуровневые протоколы, пытался понять логику их работы и назначение передаваемых параметров.

Безусловно, православный путь — снизу вверх: от азов установления физических и логических управляющих каналов Bluetooth к базирующимся на их основе высокоуровневым протоколам. Этим путем я вас и попробую провести.

Ядро блютуса — Bluetooth Core System Specification — описывает четыре базовых нижних уровня архитектуры и соответствующие протоколы, причем три нижних уровня, как правило, выделяют в отдельную подсистему — Bluetooth Controller, а все, что находится выше — относится к Bluetooth Host.

Структурная схема архитектуры Bluetooth Core System показывает расположение основных блоков архитектуры на уровнях модели, обозначает user-plane и control-plane трафик между блоками и, самое главное, дает представление об иерархичности стека.

Беспроводной звук. Препарируем Bluetooth

На схеме не сделан акцент на очень важной части архитектуры — Host to Controller интерфейсе (HCI), обеспечивающем взаимодействие софтовой подсистемы Host с железной подсистемой Controller. Всё взаимодействие верхних уровней Bluetooth системы с ее аппаратной частью происходит через HCI-команды, инициируемые драйвером. Эти команды в дампе будут нам встречаться постоянно.

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

RF.

developer.bluetooth.org/TechnologyOverview/Pages/Radio.aspx Блок Radio (он же PHY), как и подобает резиденту физического уровня, занимается преобразованием битовой последовательности в радио сигналы. Вопросы модуляции, спектральных характеристик и физики процессов обеспечения битовой скорости — все это решается на нижнем уровне модели.

Baseband Layer = Link Controller + Baseband Manager + Device Manager.

Уровень Baseband представлен в виде трех блоков, совместная задача которых состоит в управлении физическими каналами (Phy channels), поверх которых устанавливаются физические соединения (Phy links). Bluetooth-адресация, синхронизации генераторов устройств, управление кодами доступа к физическим каналам, поиск устройств и установление физического канала между ними — все это задачи Baseband-уровня.

Link Manager.

После того, как два нижних уровня обеспечили нас физическим соединением между master-slave устройствами, дело становится за организацией логических каналов, которые впоследствии и станут базой для передачи трафика приложений. developer.bluetooth.org/TechnologyOverview/Pages/LMP.aspx Link Manager в ответе за установление, изменение и освобождение логических соединений между устройствами, а так же за обновление параметров физических соединений. Для этих целей Link Manager использует Link Management протокол (LMP).

L2CAP Layer = Channel Manager + L2CAP Resource Manager.

Переваливаемся в высокоуровневый блок Bluetooth Host, оккупированный L2CAP уровнем. Logical Link Control and Adaptation Protocol (L2CAP) — протокол, работающий поверх созданных логических соединений, обеспечивающий инкапсуляцию, сегментацию и восстановление пакетных данных от всех вышележащих приложений.

Транспортная архитектура.

В процессе знакомства с блоками архитектуры у вас уже могла выстроиться картина общей транспортной архитектуры Bluetooth, которая представляет собой трехуровневую модель:

Беспроводной звук. Препарируем Bluetooth

В дальнейшем в тексте я буду использовать слово “каналы” для обозначения Channels и “соединения” для Links.

Беспроводной звук. Препарируем Bluetooth

На картинке выше представлен путь юникастного асинхронного трафика по транспортной архитектуре. Именно этот тип трафика характерен для передачи “пакетного” аудио.

SCO vs ACL.

Если внимательно посмотреть на предыдущий рисунок, то на уровнях Logical Links и Logical Transports чаще всего встречаются аббревиатуры ACL и (e)SCO. Это два глобальных типа логических соединений между Bluetooth-устройствами, которые служат для передачи разного рода трафика вышестоящих приложений.

По ACL (Asynchronous Connection-Oriented Links) соединениям передается асинхронный, пакетный трафик с возможностью повторной отправки в случае потерь при доставке, сегментации и управления потоком.

SCO-соединения, в свою очередь, по сути организованы по принципу коммутации каналов с постоянной пропускной способностью 64кбит/с и синхронной передачей данных в тайм-слотах. SCO-каналы, например, используются профилем Headset для потоковой передачи голоса абонента от телефона к гарнитуре.

Согласно архитектуре Host Controller Interface, каждая его команда (HCI command) должна сопровождаться ответным событием (HCI Event). Ответ всегда возвращает статус команды (Success или код ошибки), а так же, опционально, запрошенные командой значения.

Ниже приведены три HCI команды на этапе самоинициализации модуля и события-ответы на них.

Беспроводной звук. Препарируем Bluetooth

Поиск и обнаружение устройств.

После того, как Bluetooth собрал информацию “о себе”, я запустил поиск устройств. Когда вы зажимаете кнопку до состояния мигающего индикатора, устройство переводится в режим прослушивания канала обнаружения (Inquiry Channel). Когда девайс услышит код доступа “ответьте все” на этом канале, он отправит информацию о своем присутствии.

Как и любой процесс обращения верхних уровней к железной части Bluetooth, все начинается с команды от HCI:

Беспроводной звук. Препарируем Bluetooth

Здесь интерес представляет поле LAP. На самом деле это ни что иное, как аналог мультикаст адреса (general access code), увидев который на канале обнаружения, Bluetooth-устройства обязательно оповестят о своем присутствии ответным сообщением.

В итоге все девайсы, получившие general access code на своем физическом канале для обнаружения, отвечают сообщениями Inquiry Response, в которых:

Беспроводной звук. Препарируем Bluetooth

указан MAC адрес устройства, его главный и второстепенные классы (Major Class и Minor Class), а также поддерживаемые сервисы.

Я выделил два параметра: первый — Sink — свидетельствует о том, что устройство может выступать в роли приемника аудиосигнала, а второй — Advanced Audio Distribution — что аппарат поддерживает тот самый A2DP-профиль.

Подключение

После процедуры поиска картина мира для Bluetooth-устройства становится ясна, самое время переходить к фазе подключения, или, как этот процесс называют в спецификации — Paging.

Беспроводной звук. Препарируем Bluetooth

Для подключения оборудования также выделен отдельный физический канал. Важно отметить, что физические каналы Bluetooth работают в режиме двусторонней передачи (дуплекс). Использование одного физического канала для двунаправленной передачи осуществляется по принципу временного разделения каналов (TDM). При таком подходе передатчик и приемник должны иметь синхронизированные тактовые генераторы, чтобы передавать и принимать информацию в нужные моменты времени.

Так как каждое Bluetooth-устройство оснащено своим собственным генератором, то ни о какой изначальной синхронизации между ними, естественно, речи не идет. Синхронизации добивается Link Controller в процессе установления соединения.

Происходит это следующим образом: в процессе поиска master-устройство получает от ответчиков среди прочих параметров еще и их значение тактового генератора. Затем, на этапе установления соединения master-устройство передает предполагаемое значение смещения тактового генератора для slave-устройства (параметр Clock Offset в скриншоте выше), тем самым ускоряя процесс синхронизации двух генераторов.

Самым важным полем команды Create Connection на подключение является идентификатор удаленного устройства — его Bluetooth-адрес (BD_ADDR). Вслед за командой контроллеру на установление соединения в бой вступает LMP протокол, который полностью управляет процессом организации логических соединений, поверх которых впоследствии будет гулять наш трафик:

Беспроводной звук. Препарируем Bluetooth

Если помните, в начале статьи я рассказывал о методе Adaptive Frequency Hopping, позволяющем избежать интерференции на уже занятых частотах? Так вот, карта используемых частот как раз и передается в LMP сообщении Set AFH. В процессе работы я замечал новые появления данных пакетов с другой картой частот, что свидетельствует о постепенном мониторинге эфира на предмет страдающих от интерференции каналов.

Итогом процесса установления соединения станет присвоение связи двух Bluetooth устройств идентификатора Connection Handle.

Сопряжение (Pairing).

Окей, мы установили физическое соединение с устройством, синхронизировали генераторы устройств и готовы к передачи служебной и пользовательской информации в тайм-слотах, чего не хватает? Спаривания. Наши устройства пока не доверяют друг другу, а значит никакой пользовательский трафик недопустим к передаче.

Т.к. оба устройства поддерживают версию спецификации Bluetooth 3.0, то им доступен метод аутентификации Secure Simple Pairing (и его подметод Just Works), позволяющий аутентифицировать и авторизовать устройства без ввода каких-либо пин-кодов.

L2CAP in action.

В главе, посвященной транспортной архитектуре, изображена схема иерархии каналов и соединений, на вершине которой находится L2CAP-протокол. Именно его очередь и наступает сразу после процессов аутентификации устройств.

Структурная схема архитектурных блоков L2CAP-уровня повествует о его возможностях по сегментации, повторной отправке, управлению потоками и ресурсами:

Беспроводной звук. Препарируем Bluetooth

При этом важно уяснить, что асинхронные данные от любых приложений будут скормлены L2CAP-протоколу, который подготовит данные к отправке нижним уровням стека.

Для того, чтобы от процедуры спаривания устройств перейти к непосредственно информационному обмену, хорошо бы знать, а какие профили поддерживает сопряженное устройство, умеет ли оно воспроизводить аудио или орагнизовывать обмен файлами? На эти вопросы отвечает протокол Service Discovery (SDP). Так как это протокол верхнего уровня, ему не обойтись без услуг L2CAP-протокола, который специально для этого создаст канал. Давайте посмотрим, как это происходит.

В моем примере после успешного спаривания устройств появился первый L2CAP-пакет, содержащий следующие поля:

Беспроводной звук. Препарируем Bluetooth

Команда Connection Request, как подсказывает КО, инициирует создание соединения с L2CAP уровнем slave-устройства, при этом в структуре пакета есть интересные для нас поля.

L2CAP протокол использует концепцию каналов, конечные точки такого канала в паре master-slave идентифицируются при помощи 2-байтного CID (Channel Identification). CID 0x0001 — зарезервированный идентификатор канала для терминирования трафика сигнализации L2CAP протокола, что логично, ведь именно к сообщениям сигнализации относится команда Connection Request (Channel ID: 0x0001 в нижней части скриншота).

Следующее важное поле — это PSM (Protocol/Service Multiplexer). Значение PSM говорит о том, для какого протокола или сервиса мы организовываем L2CAP канал и, как видите, речь идет о канале для Service Discovery Protocol.

Service Discovery.

L2CAP хорошо потрудился и организовал канал для передачи данных протокола верхнего уровня SDP, который, как мы выяснили, поможет узнать, какие сервисы поддерживаются на удаленном устройстве.

Происходит это в форме следующего диалога:

— умеешь ли ты “_какой-нибудь сервис_”?

— да, умею, и вот его характеристики (в противном случае ответ “нет, не умею, спрашивай далее”).

На запросы всех сервисов, кроме Audio Sink и AV Remote Controller я получил негативный ответ, а значит колонка, что логично, умеет только воспроизводить аудио и давать управляющие сигналы мастер устройству (например при нажатии на кнопку pause на колонке, на паузу устанавливается проигрывание у источника).

После того, как SDP узнал о собеседнике все, что мог, самое время переходить к непосредственной передаче аудио, за которую отвечает…

Audio/Video Distribution Transport Protocol.

За организацию и управление аудио/видео потоками отвечает именно этот парень. И в моем случае разобраться в логике его работы можно было, даже не погружаясь в 160-страничную спецификацию.

Диаграмма работы AVDTP довольно понятна. Чтобы запустить поток, требуется открыть два канала: один управляющий (signalling) и один, непосредственно, для передаваемых аудио/видео данных.

Беспроводной звук. Препарируем Bluetooth

Как мы уже знаем, никуда не деться от L2CAP, именно по его каналам сверху будет идти трафик AVDTP-протокола.

L2CAP канал в этом случае открывается с новым значением PSM, соответствующим протоколу AVDTP.

Один L2CAP канал открылся для сообщений сигнализации, второй для данных AVDTP, а третий для Audio/Video Control Transport Protocol (для передачи сигналов от колонки к источнику звука) инициировала колонка.

Беспроводной звук. Препарируем Bluetooth

Обратите внимание на пары Source CID/Destination CID, это точки входа для L2CAP-каналов. Пара Src/Dst CID однозначно определяет L2CAP-канал.

После установления нужных L2CAP-каналов запустился процесс обмена служебными сообщениями между AVDTP-протоколами на обеих сторонах соединения. Среди служебных сообщений стоит отметить:

Беспроводной звук. Препарируем Bluetooth

Команда Discover позволяет узнать у удаленного устройства, а, собственно, что конкретно оно может предложить в рамках аудио/видео передачи. В ответ должно прийти описание возможностей в виде списка Service Endpoints (точек предоставления сервиса).

На первый взгляд непонятно, почему у колонки две точки в роли “приемник аудио”. На этот вопрос отвечает следующая пара сообщений:

Беспроводной звук. Препарируем Bluetooth

Обратите внимание на пару значений Min Bitpool и Max Bitpool, вскоре они сыграют важную роль.

Беспроводной звук. Препарируем Bluetooth

Так как Klipsch KMC3 умеет понимать два кодека — обязательный для A2DP-устройства SBC кодек и опциональный, проприетарный AptX кодек — то мы и видим две точки предоставления AVDTP-сервиса, они отличаются только типом поддерживаемого кодека, не более того.

AptX vs SBC.

После получения сведений о возможностях сервисных точек AVDTP протокол сообщением Set Config выбирает работу с кодеком AptX.

Так было с Klipsch, но Edifier Spinnaker не поддерживает кодек AptX, поэтому его список сервисных точек состоял ровно из одной штуки с обязательным кодеком SBC (Low Complexity Subband Coding). В итоге дампы, снятые при установлении к двум системам, отличались лишь в выбранном кодеке передаваемого аудио!

Окей, но ведь AptX такой навороченный, платный, закрытый и пиарящийся на CeBITах, почему он, собака, начинает “замирать” в определенных условиях, и можно ли как-то заставить работать колонку Klipsch с SBC-кодеком, чтобы убедиться, что проблема именно в этом?

Для проверки я подключился к Edifier, повторил опыт с расположением ноутбука за своим телом во время записи дампа, и вот, что я увидел. Ниже представлен фрагмент AVDTP-протокола, содержащий в себе закодированный кодеком SBC фрагмент передаваемого аудио.

Беспроводной звук. Препарируем Bluetooth

Т.к. SBC — кодек открытый, то в дампе можно увидеть относящуюся к нему информацию, связанную с передаваемыми аудиоданными. В спецификации A2DP подробно описана работа SBC-кодека, откуда можно выяснить, что одним из ключевых параметров, влияющих в итоге на качество кодирования, является значение bitpool.

Из дампа видно, что значение bitpool для данной порции трафика равно 48, но стоило мне закрыть телом путь от ноутбука до колонки, как значение bitpool стало снижаться, сопровождаясь прерываниями и щелчками.

После того, как значение bitpool устаканилось на уровне 30, щелчки пропали, проигрывание аудио стало вновь непрерывным. Все указывало на то, что кодек выполнил автоподстройку, заметив деградацию качества сигнала.

Но неужели я своим бренным телом вносил такое существенное затухание? Что ж, время взглянуть на график индикации уровня мощности принимаемого сигнала:

Беспроводной звук. Препарируем Bluetooth

Хорошее тело, качественно вносит затухание, о которое и спотыкаются кодеки. Вот только SBC-кодек подстроился под эти условия, снизив качество кодирования, а тем самым и необходимую пропускную способность, а AptX, по-видимому, нет.

Чтобы окончательно убедиться в том, что виноват AptX, я отключил его поддержку в Mac OS X и снова стал домогаться до Klipsch. Теперь был согласован кодек SBC между макбуком и колонкой, т.к. AptX’а ноутбук был принудительно лишен. Стоит ли говорить, что с SBC-кодеком Klipsch перестал так сильно заикаться в условиях падения уровня мощности сигнала?

Долго ли коротко, но проблема диагностирована, и ввиду закрытости AptX у меня не было никаких шансов повлиять на работу кодека (как это можно сделать с SBC, задав вилку значений bitpool в OS X). Поэтому осталось лишь не маячить телесами на пути видимого сигнала или использовать трюк с отключением кодека AptX в макоси.

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

PS1 Кстати, AptX не зря денег просит, передача аудио с его помощью через Bluetooth действительно лучше, чем с стандартным SBC. Это удалось почувствовать, отключив AptX на ноутбуке и прослушав те же треки на той же акустике. Субъективно — разница между SBC и AptX — примерно как между 192 kbps MP3 и 320 kbps — заметна, если вслушиваться.

Поддерживется AptX пока лишь узким кругом устройств, среди которых можно выделить железки под OS X и топовые смартфоны Samsung Galaxy, HTC One. Соответственно, iPhone и iPad в моем окружении именно по причине отсутствия AptX вели себя лучше, чем макбук, т.к. с ними согласовывалось использование SBC-кодека, а макбук лез с AptX.

PS2 На очереди препарация AirPlay.

PS3 И напоследок обзор Edifier Spinnaker, с которых вся эта эпопея длиною в месяц и началась.

С. Демидов

Акции