Беспроводные технологии передачи звука на базе Bluetooth: что же лучше? / forpes.ru

Главная
Беспроводные технологии передачи звука на базе Bluetooth: что же лучше?

Беспроводные технологии передачи звука на базе Bluetooth: что же лучше? +32

18.12.2018 08:47

gjf 65 13300 Источник

С развитием технологий так привычные всем «ламповые» аналоговые наушники уходят в историю – их всё больше вытесняют беспроводные собратья на базе Bluetooth.

Современные смартфоны лишаются привычного разъёма в угоду влаго- и пылезащищённости.

Разработчики выпускают всё новые версии протокола Bluetooth и всё новые версии кодеков, обещая «быстрее, выше, сильнее» — меньшие задержки в воспроизведении и лучшее качество.

Настолько ли всё хорошо? Давайте посмотрим.

Введение

Я не буду углубляться в техническую реализацию протоколов, а также в скучные спецификации. Уважаемый ValdikSS, который в большой степени выступил вдохновителем и даже научным консультантом в этой статье, готовит исчерпывающий материал касательно кодеков – и там всё будет изложено куда более подробно и технически верно.

Рассказать я хочу в большей степени о личном опыте. Ну и немножко занимательной (скучной?) практики.

Полтора года назад я загорелся идеей aptX. Да, я прочитал массу обзоров наподобие этого и поверил во все эти технические навороты и возможности. Родился ребёнок – и очень хотелось ночью с женой смотреть передачи в наушниках, не создавая шума и не будя никого в доме.

Во что же это вылилось?

Качество

Начнём с цифр и фактов (привет, Википедия!)

SBC – старый добрый кодек, обязательный при соблюдении стандарта A2DP. Кодек – результат работы Франса де Бонта (F. de Bont, M. Groenewegen and W. Oomen, «A High Quality Audio-Coding System at 128 kb/s», 98th AES Convention, Febr. 25-28, 1995) и использования алгоритмов, описанных в патенте EP-0400755B1. Примечательно, что авторы патента разрешают бесплатное использование SBC только в приложении Bluetooth, тем не менее патент истёк 2 июня 2010 года. Поскольку стандарт A2DP весьма распространён, крайне трудно найти наушники или колонки, в которых не было бы поддержки SBC.

Кодек обеспечивает частоту дискретизации 16, 32, 44.1, 48 кГц со скоростью потока 10-1500 кбит/с. Да, Вы не ослышались. До 1500 кбит/с. В кодеке просто нет лимита по битрейту. Но об этом – позже.

Кодек aptX разработан в 1988 году в Королевском Университете в Белфасте. Да, до Bluetooth ещё было ещё порядка десятка лет, так что кодек использовался в профессиональной звуковой аппаратуре. В настоящий момент права принадлежат компании Qualcomm, а потому использование требует лицензирования и лицензионных отчислений. По состоянию на 2014 год стоимость приблизительно такова: единовременный платёж $6000 и ?$1 за каждое выпущенное устройство для партий до 10000 устройств. По этой причине многие устройства с чипами Snapdragon 835, 845, 821, 820, 810, 805, 801, 800, 650, 615, 410 вполне возможно и поддерживают aptX, но он там не активирован, поскольку лицензия не была приобретена. Об этом – также ниже.

При разрядности 16 бит и частоте дискретизации 48 кГц кодек может обеспечивать скорость потока 384 кбит/с (dual channel).

Список продуктов, официально поддерживающих aptX. На Aliexpress можно найти очень много неведомых систем с поддержкой aptX, но будьте готовы к тому, что на поверку там окажется тот же старый добрый SBC – и не более.

aptX HD – тот же самый кодек, но с другим профилем кодирования, имеет скорость потока 576 кбит/с, поддержку частоты дискретизации до 48 кГц и разрядность до 24 бит. Некоторые называют этот кодек aptX Loseless – но это полный бред хотя бы потому, что в настоящий момент невозможно достигнуть значения потока, который мог бы переносить loseless-данные. Особым преимуществом этого кодека регулируемая задержка кодирования, которая может снижаться до 1 мс при частоте дискретизации 48 кГц. Также кодек крайне выгоден с позиции загрузки процессора, в чём выражается преимущество по сравнению с МР3 и ААС.

Список продуктов, официально поддерживающих aptX HD. Он достаточно невелик.

aptX Low latency (или LL) – специальная версия кодека, позволяющая снизить время задержки звука до менее 40 мс. Список продуктов, официально поддерживающих aptX LL.

Вот она. Именно эта картинка в своё время купила меня с потрохами. Задержки! Ведь кому захочется слышать звук взрыва в каком-то боевике, крик монстра в ужастике или рёв толпы на футбольном матче, когда всё уже закончилось?

Но так ли всё это на самом деле?

Увы, нет.

Как и в любом маркетинговом материале, цифры притянуты за уши. Задержка во многом зависит от буферизации в системе и реализации кодека. Так, задержка с SBC вполне может быть на уровне менее 40 мс, что принимая во внимание стандарты телевизионного вещания (+40 мс… ?60 мс) – вполне допустимо.

Резюмируя:

Ни один существующий кодек не может быть лучше проводной технологии, поскольку ни один кодек не позволяет достичь истинного сжатия без потерь.
Самым популярным кодеком является SBC. Он же – наиболее гибок в настройках. И несмотря на то, что aptX был выпущен ранее, он не смог побить популярности SBC, видимо, из-за бесплатности последнего.
Качество звука крайне зависит от реализации кодека, а также от аппаратного исполнения наушников/колонок вообще – если сама по себе колонка слабая, то качество не улучшишь ни одним кодеком. Поэтому в дальнейшем, сравнивая качество, мы будем говорить о воспроизведении одного и того же контента от одного и того же источника на одних и тех же колонках/наушниках, но с различными кодеками.

Практические и очень субъективные итоги

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

Опыт базируется на прослушивании loseless на плеере SONY Walkman NWZ-A17, где кодек можно выбирать, а также на просмотре различных передач с выводом звука посредством Avantree Priva III.

Наушников было трое: Sennheiser PMX 60, Koss Porta Pro и Koss UR-20.

В качестве приёмников беспроводного сигнала использовались Jabra BT3030 (SBC) и Avantree Clipper Pro (aptX).

Также использовалась колонка Voombox Outdoor (SBC) и наушники с костной проводимостью Aftershokz Trekz Titanium (aptX).

Все эквалайзеры и улучшатели отключались — и это важно.

Итого:

Качество проигрываемого звука при проводном подключении — всегда лучше. Это без сомнения.
Разницу между SBC и aptX услышать крайне затруднительно — и только в случае некоторых типов музыки. Например, автор статьи чётко слышал разницу на соло виолончелей в классических композициях, при этом для скрипки и инструментов низких частот разница была менее уловима. На современных жанрах — поп, электронная музыка и рок — разницу не слышно. В ряде случаев субъективно казалось, что SBC лучше передаёт звук, чем aptX.
Задержку между SBC и aptX можно заметить только если подключится к одному источнику и разные приёмники вставить в разные уши (ну левый канал — SBC, а правый — aptX к примеру). Задержку с картинкой увидеть практически нереально, а потому история, что aptX предназначен для динамичных сцен и контента — миф.
Удивление вызвало качество звучания на довольно дешёвых и «не именитых» Voombox Outdoor. Видимо, это и есть удачная реализация SBC, о которой говорилось выше.
Совершенно непонятна реализация aptX в наушниках с костной проводимостью – технология весьма специфична, а потому потери в качестве значительны из-за самой технологии. Принимая во внимание малый диапазон «дальности» работы устройства, крайне плохую реализацию сопряжения с двумя устройствами могу констатировать, что Aftershokz – компания, которая больше вкладывает в маркетинг, чем в разработку.

Не спорю, что если подключать всяческие спектральные анализаторы и прочее — можно и нужно увидеть разницу. Но человеческое ухо, а ещё хуже — среднестатистическое человеческое ухо — не спектральный прибор, а потому все эти нюансы не слышит.

Практика: исправляем то, что можно исправить

Часть 1. Включаем aptX

Как уже было сказано, в некоторых устройствах использование aptX отключено, вероятно, во избежание патентных преследований.

Этот вопрос можно решить достаточно просто – подсунув устройству библиотеки для реализации работы кодека и прописав возможность работы с этим кодеком в build.prop.

На просторах интернета имеется большое количество решений такого характера. Я взял на себя смелость объединить их в одно, при этом реализовав в виде модуля для Magisk. Да, я очень люблю этот проект и считаю, что реализация изменений в системе в виде модулей Magisk – лучше и безопасное решение с возможностью сохранения системы максимально в первозданном виде и лёгким способом отката назад.

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

Записи в build.prop, включающие aptX, а при возможности – и aptX HD, будут эмулироваться модулем автоматически.

Часть 2. Повышаем битрейт SBC

Как уже сообщалось, кодек SBC принципиально не имеет ограничений по битрейту. Однако производители обычно ставят ограничение в 342 кбит/с для моно- и 345 кбит/с для стереосигнала с целью обспечения надёжной работы со всеми типами принимающих устройств.

При этом спецификация A2DP v1.2, которая была активна с 2007 по 2015 год, предписывает всем декодирующим устройствам корректно работать с битрейтами до 320 кбит/с для моно- и 512 кбит/с в случае стереосигнала.

В новой версии спецификации ограничение по битрейту отсутствует вообще. Предполагается, что современные наушники, выпущенные после 2015 года и поддерживающие EDR, могут поддерживать битрейты до 730 кбит/с.

По факту это конечно же не так. В обширном исследовании, проведённом ValdikSS, было найдено, что практически все приёмные устройства надёжно работают со значениями битрейта 454 кбит/с, и достаточно большое количество – с битрейтом 507 кбит/с.

В своих исследованиях ValdikSS также показал, что, вопреки расхожему мнению о качестве звука кодека aptX, на некоторых файлах он может давать результаты хуже, чем SBC со стандартным битрейтом в 328 кбит/с, а переключившись в высокобитрейтный SBC, Вы получите звук, зачастую превосходящий aptX, на любых наушниках.

ValdikSS на основании этих данных направил замечания разработчикам Lineage OS и в Google, но на данный момент никакой реакции не последовало.

Таким образом, нам остаётся только вручную внести модификации в Bluetooth-стек.

Нам потребуется IDA Pro с возможностью декомпилирования ARM, любой HEX-редактор (я использовал WinHEX) и файл bluetooth.default.so с нашего устройства. Обычно он находится по пути /system/lib/hw и реже – ещё и по пути /system/lib64/hw (безусловно нужен рут-доступ).

Итак, открываем файл bluetooth.default.so Описанные ниже операции и модификации применимы только к оригинальному стеку Android (bluedroid). Если вы видите строку «Needed Library 'com.qualcomm.qti.bluetooth_audio@1.0.so'» или подобную в IDA Pro, с большой вероятностью, эта инструкция вам не поможет.

Наша первая задача — заменить Joint Stereo на Dual Channel в стандартной конфигурации.

Работать мы будем с функцией bta_av_build_src_cfg.

Чтобы отыскать эту процедуру в IDA, воспользуемся поиском по строке характерного сообщения в журнал отладки «Cant parse src cap ret = %d»:

В итоге довольно быстро мы находим саму функцию в виде кода:

Наша задача – подменить исходную структуру проверок

    if (src_cap.ch_mode & A2D_SBC_IE_CH_MD_JOINT)
        pref_cap.ch_mode = A2D_SBC_IE_CH_MD_JOINT;
    else if (src_cap.ch_mode & A2D_SBC_IE_CH_MD_STEREO)
        pref_cap.ch_mode = A2D_SBC_IE_CH_MD_STEREO;
    else if (src_cap.ch_mode & A2D_SBC_IE_CH_MD_DUAL)
        pref_cap.ch_mode = A2D_SBC_IE_CH_MD_DUAL;
    else if (src_cap.ch_mode & A2D_SBC_IE_CH_MD_MONO)
        pref_cap.ch_mode = A2D_SBC_IE_CH_MD_MONO;</code>
на
<code>    if (src_cap.ch_mode & A2D_SBC_IE_CH_MD_DUAL)
        pref_cap.ch_mode = A2D_SBC_IE_CH_MD_DUAL;
    else if (src_cap.ch_mode & A2D_SBC_IE_CH_MD_STEREO)
        pref_cap.ch_mode = A2D_SBC_IE_CH_MD_STEREO;
    else if (src_cap.ch_mode & A2D_SBC_IE_CH_MD_DUAL)
        pref_cap.ch_mode = A2D_SBC_IE_CH_MD_DUAL;
    else if (src_cap.ch_mode & A2D_SBC_IE_CH_MD_MONO)
        pref_cap.ch_mode = A2D_SBC_IE_CH_MD_MONO;

Это можно сделать несколькими способами.

Первый – подмена инструкций TST.W R0, #1 на TST.W R0, #4 и MOVS R0, #1 на MOVS R0, #4 в последовательности проверок:

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

10 20 8D F8 04 00 9D F8 0D 00 10 F0 01 0F ?? ?? 10 F0 02 0F ?? ?? 10 F0 04 0F ?? ?? 10 F0 08 0F ?? ?? 08 20 ?? ?? 01 20 ?? ?? 02 20 ?? ?? 04 20

и её замена на

?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 04 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 04 ?? ?? ?? ?? ?? ?? ?? ?? ??

Однако у данного способа есть недостатки.

Ряд компиляторов меняют последовательность исполнения команд в зависимости от оптимизации. И в таком случае найти искомый паттерн не удаётся, а иногда механизм проверок в структуре вообще вносится в инлайн-код. Поэтому более надёжным является изменение константы btif_av_sbc_default_config.

Для начала – найдём её. Она в самом начале нашей функции, ведь

void bta_av_build_src_cfg (UINT8 *p_pref_cfg, UINT8 *p_src_cap)
{
    tA2D_SBC_CIE    src_cap;
    tA2D_SBC_CIE    pref_cap;
    UINT8           status = 0;
    /* initialize it to default SBC configuration */
    A2D_BldSbcInfo(AVDT_MEDIA_AUDIO, (tA2D_SBC_CIE *) &btif_av_sbc_default_config, p_pref_cfg);
    /* now try to build a preferred one */
    /* parse configuration */
    if ((status = A2D_ParsSbcInfo(&src_cap, p_src_cap, TRUE)) != 0)
    {
         APPL_TRACE_DEBUG(" Cant parse src cap ret = %d", status);

А вот и она:

Видно, что сама btif_av_sbc_default_config представляет собой последовательность байт 20 01 10 04 01 35 02, при этом первый байт кодирует частоту дискретизации и может быть 10 (48 кГц) и 20 (44 кГц), а потому не специфичен. Таким образом наша задача – замена последовательности
01 10 04 01 35 02
на
04 ?? ?? ?? ?? ??

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

В ряде случаев инициатором подключения выступают сами наушники или колонки. В этом случае режим определяется функцией bta_av_co_audio_init.

Функция характерна строкой «bta_av_co_audio_init: %d» и легко отыскивается в коде:

Перечисление возможных режимов подключения выполняется в следующей команде:

    switch (index)
    {
    case BTIF_SV_AV_AA_SBC_INDEX:
        /* Set up for SBC codec  for SRC*/
        *p_codec_type = BTA_AV_CODEC_SBC;
        /* This should not fail because we are using constants for parameters */
        A2D_BldSbcInfo(AVDT_MEDIA_AUDIO, (tA2D_SBC_CIE *) &bta_av_co_sbc_caps, p_codec_info);
        /* Codec is valid */
        return TRUE;

при этом константа bta_av_co_sbc_caps имеет следующую структуру:

const tA2D_SBC_CIE bta_av_co_sbc_caps =
{
    (A2D_SBC_IE_SAMP_FREQ_44), /* samp_freq */
    (A2D_SBC_IE_CH_MD_MONO | A2D_SBC_IE_CH_MD_STEREO | A2D_SBC_IE_CH_MD_JOINT | A2D_SBC_IE_CH_MD_DUAL), /* ch_mode */
    (A2D_SBC_IE_BLOCKS_16 | A2D_SBC_IE_BLOCKS_12 | A2D_SBC_IE_BLOCKS_8 | A2D_SBC_IE_BLOCKS_4), /* block_len */
    (A2D_SBC_IE_SUBBAND_4 | A2D_SBC_IE_SUBBAND_8), /* num_subbands */
    (A2D_SBC_IE_ALLOC_MD_L | A2D_SBC_IE_ALLOC_MD_S), /* alloc_mthd */
    BTA_AV_CO_SBC_MAX_BITPOOL, /* max_bitpool */
    A2D_SBC_IE_MIN_BITPOOL /* min_bitpool */
};

Константа легко находится в коде, в моём случае она равна 20 0F F0 0C 03 35 02:

Обратите внимание на байт 0F – он обеспечивает возможность подключения с любым из допустимых режимов, поскольку

x0F = A2D_SBC_IE_CH_MD_MONO | A2D_SBC_IE_CH_MD_STEREO | A2D_SBC_IE_CH_MD_JOINT | A2D_SBC_IE_CH_MD_DUAL = x08 | x02 | x01 | x04

Наша задача — изменить это значение таким образом:

x0F = A2D_SBC_IE_CH_MD_DUAL = x04

Следовательно, необходимо заменить

?? 0F F0 0C 03 35 02
на
?? 04 ?? ?? ?? ?? ??

Итак, мы заставили стек подключаться в режиме Dual Channel как в случае инициирования подключения устройством, так и в случае инициирования подключения принимающей сигнал стороной.

Теперь необходимо убрать ограничения в битрейте либо повысить его верхний порог.

Необходимо обработать btif_media_task_get_sbc_rate. Аналогичным образом по поиску характерной строки «non-edr a2dp sink detected, restrict rate to %d» отыскиваем функцию в коде:

Ограничение битрейта выражается в строке
UINT16 rate = DEFAULT_SBC_BITRATE (что в свою очередь равно 328 кбит/с)

В коде это так:

Изменим это значение на 454 кбит/с – это выше стандартного и работает с подавляющим большинством приёмных устройств. Для этого заменим байты

B1 4F F4 A4 74 ?? E0
на
?? ?? ?? E3 ?? ?? ??

Также следует выполнить поиск по паттерну

E0 4F F4 A4 74 ?? E0
и заменить его на
?? ?? ?? E3 ?? ?? ??
— это требуется для ряда устройств.

Значение Е3 может быть другим в зависимости от желаемое максимального битрейта:

E3 – 454 кбит/с
F1 – 482 кбит /с
F3 – 486 кбит/с
10 – 576 кбит/с
48 – без ограничений

В целом, это определяется байт-кодом операции MOV.W R4, XXX.

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

На всех приёмниках в моём эксперименте (выше я их указал) таким значением было 576 кбит/с, в качестве источника сигнала выступал телефон Xiaomi Redmi 4x MIUI10 Android 7.1.

На основе описанных действий был создан дженерик-патч, который находит указанные паттерны в Bluetooth.default.so и заменяет их? включая принудительно режим Dual Channel и устанавливая лимит битрейта в 454 кбит/с. При необходимости, значение лимита может быть легко изменено на основании поиска и замены соответствующего байта — внимательный читатель сделает это без труда.

Подчёркиваю: патч работает только в случае bluedroid-стека и скорее всего не будет успешным в случае стека Fluoride и версии Android 8 и новее.

Патч можно скачать отсюда.

Замену оригинального файла настоятельно рекомендуется выполнять в виде модулей Magisk, для себя я это сделал следующим образом. Обратите внимание: данные модули сделаны мной для телефона Xiaomi Redmi 4x 3/32 Гб с актуальной на момент написания статьи стоковой глобальной стабильной прошивкой MIUI 10. В Вашем случае файл bluetooth.default.so придётся заменить на свой собственный, пропатченный, как описано выше. Возможно также, что файл придётся продублировать по пути /system/lib64/hw — это зависит от модели и версии прошивки Вашего телефона.

Данный подход с использованием модулей Magisk позволяет легко изменять максимальный битрейт и вообще отключать изменения, если окажется, что какое-то из принимающих устройств не поддерживает Dual Channel.

Заключение

В настоящий момент в погоне за продажами многие компании подают некоторые технологические новинки как обоснование более высокой цены.

На практике оказывается, что уже имеющиеся, более дешёвые технологии не до конца развиты, а технологические новинки – не до конца внедрены, что значительным образом сказывается на качестве.

Очень часто пользователи испытывают «эффект плацебо», убеждая себя в совершенстве того или иного продукта только потому, что он новее или более красочно преподнесён. По факту, это качество оказывается мнимым.

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

Нам не удалось ни получить разъяснений от Google касательно лимита битрейта в 328 кбит/с, ни добиться устранения этого лимита и добавления опции включения Dual Channel в меню Bluetooth от разработчиков Lineage OS.

Спасибо всем, кто дочитал до конца!

Некоторое продолжение, вызванное обсуждением в комментариях и пробелом в отношении кодека LDAC, находится здесь.

Комментарии (65)

xFFFF
18.12.2018 12:40
#19515454
Joint Stereo намного лучше использует полосу сигнала(битрейт).
1. gjf Автор
  18.12.2018 12:55
  #19515590
  В Joint Stereo (или Intensity Stereo) учитывается избыточность между левым и правым каналом, что используется для оптимизации кодирования.
  Безусловно, это уменьшает нагрузку на битрейт и позволяет достичь стереозвучания при низком потоке.
  Но в нашем случае мы стремимся не к «лишь бы достичь», а к качеству.
  Dual Channel выделяет ровно половину битрейта под каждый канал и не проводит «оптимизацию», то есть по сути каждый канал остаётся неизменным. И это отличает его от Stereo — когда выделение потока может изменяться, например, чтобы «не кодировать тишину».
  Классический пример: преимущественный текст в одном канале — и музыка в другом. Да, текст весьма синтетический, но даёт яркое понимание разницы режимов.
  1. SADKO
    18.12.2018 18:34
    #19518178
    Не могу не согласиться что dual channel это неоправданная жесть в сравнении со стерео, но и joint stereo он знаете, не просто учитывает избыточность как стерео, он её, эту избыточность делает, иногда даже весьма заметным на слух образом, потому его автор и выпилил…
    … хотя если основное направление трансляции всякие походные мини колонки, то тут сама физика тот joint скрутит, так-что польза в том, что-бы сделать это программно и до кодирования была-бы весьма высока
    Вот и получается, что на вкус и цвет, все фломастеры разные, и по уму надо-бы пользователю дать решать чего ему надо и в каком контексте…
    
    gjf Автор
    18.12.2018 22:36
    #19519312
    По этой причине я настоятельно рекомендую делать это в виде модулей Магиска — легко все эти изменения отключать.
    Увы, но разработчики прошивок программно это включать и отключать не дают.

Revertis
18.12.2018 12:47
#19515522
А меня интересует вопрос: бывают ли Bluetooth-наушники, у которых между треками не слышно шума?

phantom-code
18.12.2018 12:56
#19515600
Я не специалист, но тем не менее не совсем понимаю, зачем нужен весь этот зоопарк кодеков, за которые еще нужно платить отчисления? Тот же Opus (CELT+Silk) открыт, имеет низкую алгоритмическую задержку (пригоден для VoIP) и позволяет кодировать сигнал в весьма неплохом качестве. В чем проблема использовать его по Bluetooth?
1. ValdikSS
  18.12.2018 14:20
  #19516232
  Корпорации по какой-то причине опасаются использовать аудиокодеки, за которыми стоят не корпорации, а сообщества. Предположительно, из-за того, что если создатель аудиокодека — корпорация, то она гарантирует юридическую чистоту алгоритмов и, в случае чего, в суд будут подавать на неё в первую очередь, а не на пользователей (лицензиатов). В случае Opus, Vorbis и других кодеков, только предполагается, что они не нарушают никакие патенты (на сайте Xiph так и написано), но нет гарантии, что это действительно так.
  Это свойственно не только аудио, но и видеокодекам.

mistergrim
18.12.2018 13:09
#19515706
Ни один кодек не может быть лучше проводной технологии, поскольку ни один кодек не позволяет достичь истинного сжатия без потерь.
Неверно. Поскольку никто не озаботился созданием кодека со сжатием без потерь.
1. gjf Автор
  18.12.2018 13:14
  #19515748
  Как только кто-то такой напишет — я немедленно изменю это утверждение.
  1. mistergrim
    18.12.2018 13:19
    #19515812
    Тогда утверждение должно звучать так — ни один СУЩЕСТВУЮЩИЙ кодек.
    Причём непонятно, кто мешает написать, если SBC укладывается в 1500 кбит/с, при этом несжатое CD-Audio имеет битрейт 1411 кбит/с.
    
    gjf Автор
    18.12.2018 13:22
    #19515842
    Принято. По вопросу написания кодеков — думаю, его лучше адресовать специалистам в этом деле.
    
    ValdikSS
    18.12.2018 14:52
    #19516446
    +1
    В Bluetooth используется разделение эфира по времени и типы пакетов с фиксированным размером: вы не можете посылать, например, много мелких пакетов с данными 1411 кбит/с. Отправка каждого пакета занимает минимум 1.25 мс, больших пакетов, которые разумнее всего использовать для передачи аудио — 3.75 мс. Чтобы аудио не рвалось, нужно за 3.75 мс передать как минимум вдвое больше аудио, т.е. 7,5 мс, что не получается с несжатым аудио.
    Даже LDAC на битрейте 990 кбит/с нормально работает только на близком расстоянии.
    SBC — кодек общего назначения, он не делался исключительно для Bluetooth, просто так получилось, что стандартизировали именно его. В Bluetooth оптимальный максимальный битрейт — 596-598 кбит/с — в пакет умещается от 3 до 4 фреймов, по 2.9 мс каждый, т.е. 8.7-11.6 мс аудио.
    Вот здесь есть калькулятор: btcodecs.valdikss.org.ru/sbc-bitrate-calculator
    
    mistergrim
    19.12.2018 00:15
    #19519628
    А скорость передачи в Bluetooth подвержена каким-то фундаментальным ограничениям? Просто странно — тот же WiFi постоянно ускоряется, а BT как был черепахой, так и остался
    
    ValdikSS
    19.12.2018 09:05
    #19520462
    Наверное, это и не нужно. У Bluetooth гораздо ниже типичные мощности передатчика: 2.5 Вт против 100 Вт у Wi-Fi, полоса сильно уже, и в плане разделения эфира он гораздо надёжней, чем Wi-Fi.
    В Bluetooth 5 у LE добавили высокие скорости (до 3 мегабит, как и в Bluetooth Classic), и еще убрали фиксированные типы пакетов, сделали динамические слоты передачи.
1. ValdikSS
  18.12.2018 14:42
  #19516376
  +1
  Сжатие без потерь либо очень тяжело, либо невозможно вместить в пропускную способность Bluetooth. Всегда будут какие-то «композиции» (белый шум, например), который не поддается сжатию, а Bluetooth не может обеспечить надежную и бесперебойную передачу 1411 кбит/с. В моей готовящейся статье об этом будет сказано.
  1. VVizard
    19.12.2018 17:04
    #19523404
    С нетерпением жду вашу статью.
    Ваш патч для моего Galaxy S5 улучшил качество звука при подключении к автомобильному ГУ. В первую очередь улучшилось восприятие сцены, и звук стал более разборчивым. Эффект сильно меняется от трэка к треку.
    
    Думаю ваша статья многим будет полезна.
    Я думаю что если бы кто то взялся сделать универсальный патчер для Google Play (понятно что на рутированом устройстве) это было бы полезное приложение, лично я за подобное приложение без проблем отдал бы 250р. И думаю не я один.
    В общем при должном подходе это было бы уникальное приложение и несколько тысяч установок вполне реальное количество.

Gorthauer87
18.12.2018 13:11
#19515720
А такое напатчить для обычного Linux x86 реально?
1. mOlind
  18.12.2018 13:48
  #19516042
  Там можно исходники найти, поправить нормально и пересобрать.
1. ValdikSS
  18.12.2018 14:33
  #19516308
  +1
  Патч для pulseaudio: files.catbox.moe/kc6e0x.patch

lkrs
18.12.2018 13:42
#19516008
LDAC же теперь бесплатный. надеюсь станет стандартом.
1. ValdikSS
  18.12.2018 14:34
  #19516314
  +1
  Он не бесплатный. У него только есть открытый энкодер (но не декодер), и он всё равно требует лицензирования у Sony.
  1. Gordon01
    19.12.2018 09:43
    #19520592
    Вы так говорите, будто опенсорц-сообщество за 20 лет существования бютуса что-то смогло изобрести.
    По крайней мере теперь на любом свежем андроиде бесплатно есть возможность использовать кодек, который 99% не отличить от провода.
    И он требует не лицензирования, а сертификации.
    
    gjf Автор
    19.12.2018 11:11
    #19520968
    Статья вышла довольно длинная, видимо, прочитать её до конца Вы не смогли. Тем более пройти по референсам.
    Просто скажу так: отличить можно. И это не только моё субъективное мнение. Есть и другие. А если интересуют объективные факты — они, например, тут.
    Касательно лицензирования или сертификации или акцизных отчислений — не отвечу, я не юрист. Суть такова, что это требует некоторой затраты денег.
    
    Gordon01
    19.12.2018 18:47
    #19523984
    Я читал все референсы, в первый же день как они вышли и долго смеялся над тем, что великие производители железа за 20 лет так и не смогли разобраться в своем же кодеке и задействовать все его технические возможности.
    На их фоне, Сони, которые на свои вообще-то деньги, разработали кодек, который в 100% случаев на голову лучше всех конкурентов — просто боги. И еще и лично сделали патч для анроида, так что у всех владельцев 8го андроида уже по умолчанию есть поддержка LDAC.
    Единственный минус LDAC сегодня — ограниченное число приемников с его поддержкой, фактически состоящим из трех моделей наушников, выпускаемых самими сони и еще несколькими ресиверами
    
    ValdikSS
    19.12.2018 14:21
    #19522254
    Вы так говорите, будто опенсорц-сообщество за 20 лет существования бютуса что-то смогло изобрести.
    Может, оно не слишком и нужно? Я в большинстве случаев не отличаю SBC 328 кбит/с от оригинала, при обычных условиях, если не замедлять трек и не понижать частоту (делать pitch-shift). А LDAC 330 кбит/с выдает качество звука хуже, чем SBC с 328 кбит/с.
    
    Gordon01
    19.12.2018 18:42
    #19523952
    Я отличаю AptX HD от LDAC. Думаю, 10% минимум легко отличат.
    SBC и AAC звучат ужасно, скорее всего ваш слух просто имеет недостаточное разрешение.
    Большой плюс LDAC еще и в том, что в реальных условиях, на улице/в метро он гораздо меньше подвержен помехам. Тот же AptX HD и AAC заикаются гораздо чаще.
    
    gjf Автор
    19.12.2018 19:55
    #19524272
    Кажется, вслед за жертвами маркетинговых уловок aptX и иже с ним появились новые — LDAC-филы.
    
    Я думаю, что о LDAC я напишу отдельную статью. Подождите пару дней.
    
    ValdikSS
    19.12.2018 22:46
    #19524798
    Давайте это проверим. Опубликуйте ссылку на знакомую вам композицию или композиции, и я их скодирую в разные кодеки, а вы попробуете честно и не подглядывая в спектрограммы определить, где что.
    
    Gordon01
    20.12.2018 12:23
    #19527180
    Давайте, но как вы распакуете LDAC и aptX, они же закрыты?
    
    ValdikSS
    20.12.2018 12:25
    #19527200
    Для aptX есть открытый энкодер и декодер, LDAC — никак. Я хотел вам предоставить для тестов оригинал, aptX и AAC.
    
    Gordon01
    20.12.2018 13:41
    #19527896
    А в чем смысл? После того как я послушал LDAC, других кодеков для меня не существует, даже aptx HD уже не тот.
    https://youtu.be/A8MFlzT07SU вот тут в конце есть сравнение с sbc, из реальных наушников, записанные микрофоном, все отлично слышно. Я понимаю, это без вашего патча, но давайте вернёмся к реальности — число его пользователей будет примерно равно числу пользователей джейлбрейка.
    
    ValdikSS
    20.12.2018 20:41
    #19530472
    +1
    Вы либо заблуждаетесь в разнице кодеков, либо прикалываетесь.
    Если вы слышите большую разницу между aptX/HD и, например, LDAC, то, наиболее вероятно, в ваших наушниках настроены разные эквалайзеры, компрессоры и другой пост-процессинг на каждый кодек отдельно, и вы слышите разницу не между кодеками как таковыми, а между разными настройками DSP внутри наушников, на которые вы влиять не можете.
    
    Вы привели ссылку, где на микрофон записали звук разных наушников. Какое оно имеет отношение к обсуждаемому вопросу?
    
    У меня есть живой, не синтетический пример:
    Оригинал
    SBC
    SBC-файл (Joint Stereo, 328 кбит/с — самый обычный, наиболее часто используемый профиль) я получил путем воспроизведения FLAC-файла с телефона (Blackberry Q10) на компьютер по Bluetooth 4.0, и записью звука на компьютере из виртуального выхода аудиокарты. Я не слышу разницы.
    
    Gordon01
    20.12.2018 21:39
    #19530718
    -1
    То есть аргументы свелись к "ты жертва маркетинга сони"? Тогда тоже перейду к низкокачественном приёмам демагогии.
    
    В 1000х нельзя включить никакую обработку, если кодек отличен от SBC. Если вы такой эксперт, как говорите, то должны были это знать. Судя по всему, вы никогда 1000х не слушали, а просто теоретизируете.
    
    ValdikSS
    20.12.2018 23:40
    #19531154
    Причём тут маркетинг? На видео тестируют разные наушники, и записывают их звук на микрофон. Что это видео показывает? Что у разных наушников разный звук? Причем тут LDAC? Причем тут наушники как таковые, если речь о кодеках? Может, я что-то не понимаю?
    
    Я ни в коем случае не эксперт, и разбирался в Bluetooth-аудио и кодеках в всего течение 3 месяцев, просто из интереса. Упор делал преимущественно на SBC, но и о других читал. Я могу ошибаться, указывайте на это, если это так. Для получения информации большей, чем есть в интернете, я связывался с разными людьми, в том числе с создателем открытой реализации openaptx, декодера ATRAC9, с автором серии статей о Bluetooth-аудио на soundguys (вот его статья об LDAC, к слову; тесты проводились на ресивере с поддержкой LDAC, который подключали по SPDIF), и проводил различные тесты на десятках моделей наушников и ресиверов. Также сделал патч для поддержки SBC Dual Channel для Android, добавляющий галочку «HD Audio: SBC» в настройки Bluetooth-аудиоустройства, и загрузил его в виде серии патчей в Google (это к упрёку о том, что сообщество ничего не делает).
    
    Скрытый текст
    
    gjf Автор
    20.12.2018 10:37
    #19526384
    Как и обещал: habr.com/post/433724

dMac
18.12.2018 15:03
#19516540
Позвольте возразить. Человеческое ухо — как раз таки вполне себе спектральный прибор, читаем Алдошину и других ученых в области психоакустики.
Другое дело, что этот спектральный прибор в большинстве случаев очень паршиво откалиброван
1. gjf Автор
  18.12.2018 15:07
  #19516568
  Прибор — тогда и прибор, когда обеспечивает единобразие измерений.
  А когда «калибровка» различна от прибора к прибору — это не прибор, потому что каждое «измерение» будет уникально в зависимости от применяемого «прибора».
  В сущности, это и наблюдается )))
  1. dMac
    18.12.2018 15:09
    #19516586
    Акцент был на слове «спектральный», а не на слове «прибор»

dMac
18.12.2018 15:08
#19516576
del

lonelymyp
18.12.2018 22:40
#19519320
Хм
А насколько это применимо к Windows?
Можно ли увеличить битрейт блютус передатчика например на ноутбуке?
1. gjf Автор
  18.12.2018 22:43
  #19519332
  Боюсь, что это всё находится внутри драйвера. Редактировать это можно, но нет исходного кода, а потому процесс более трудоёмкий и связан со бсодами.
  И даже в случае успеха — кто подпишет отредактированный драйвер?
  1. lonelymyp
    19.12.2018 00:07
    #19519604
    Беглый гуглёж показал что можно пробросить внешний блютус адаптер в виртуалку с линуксом и патченными драйверами. Но пожалуй это не очень удобно.
    А так же есть довольно старая статья про btav.ini и Bluesoleil.
    
    Вот там кстати нашёлся внушительный список протестированных ушей 4pda.ru/forum/index.php?s=&showtopic=914135&view=findpost&p=76170413
    Как оказалось, есть которые могут 600 и выше, альтернатива поиску ушей с поддержкой aptx + покупка адаптера с поддержкой aptx.
    
    VVizard
    19.12.2018 17:11
    #19523464
    Я как и вы сильно заблуждался на счет aptx (да еще и что то доказывал в сетевых баталиях), спасибо ValdikSS который разбил маркетинговый бред в моей голове.
    aptx вообще не выход и в некоторых случаях он реально даже хуже SBC работает.
    ValdikSS сделал патч для моего телефона который поднял битрейт SBC и включил Dual Chanel. Я в машине всегда слушаю музыку с телефона через BT и после патча многие любимые треки зазвучали по новому.
    При этом на этих треках я всегда понимаю что патч не включился (Если при включении телефона не телефон к ГУ подключился а ГУ к телефону то патч не срабатывает).
    
    lonelymyp
    19.12.2018 21:35
    #19524594
    Под винду особо выбирать не приходится, либо sbc на минимуме, либо уши с aptx и внешний донгл к ним.
    На ноутбуке это вдвойне печально так как там и так мало портов внешних, чтобы один занимать донглом.
    
    ValdikSS
    19.12.2018 22:52
    #19524818
    В Windows 10 есть поддержка aptX.
    
    lonelymyp
    20.12.2018 20:14
    #19530380
    То что она там есть, не означает что ей можно пользоваться просто так.
    Нужны наушники с поддержкой aptx и к ним в добавок usb блютус адаптер поддерживающий aptx.
    
    ValdikSS
    20.12.2018 21:02
    #19530564
    Нет, должно работать независимо от адаптера. У меня работает на всех. Это обычная софтовая реализация, которую добавили в Windows 10 build 1709.
    
    lonelymyp
    20.12.2018 22:03
    #19530826
    Независимо от адаптера при условии что он один из Intel 8260/7265/7260/3165/3160? :)
    Хотя это открывает некоторый простор для модернизации ноутбука, это всётаки лучше чем внешний адаптер.
    
    И всё равно ещё нужны наушники с aptx, включение функции в компьютере это лишь половина дела.
    
    ValdikSS
    21.12.2018 00:19
    #19531302
    В Windows 10 build 1709 добавили поддержку aptX. Общую, на уровне системы, независимо от адаптера и драйверов. У меня работает на всех адаптерах, в том числе на адаптере Cellink BTA-6030, 2005 года выпуска.
    Драйверы Intel, CSRHarmony и некоторые другие поддерживали aptX еще на Windows 7.

ns3230
19.12.2018 01:51
#19519906
Имею в наличии пару недорогих китайских наушников с BT и могу поделиться своими наблюдениями. Испытуемый смартфон — Mi Max 3. Первые уши — дешевые i7s TWS, купленные чет в районе 6 баксов. Если говорить в целом — стыд и срам. Работают в SBC, задержка такая, что видео смотреть без мучений не возможно. Как на глаз — до полсекунды, плюс-минус трамвайная остановка (может 300 мс, а может и 550, но много). Вторые — KZ BTE, уже поприличнее моделька и по цене ($22), и по звучанию в разы лучше. У них есть aptX, SBC, AAC. Задержка существенно меньше, по ощущениям в районе 100 мс, но разницы между кодеками действительно нет. На всех трех примерно одинаково. При этом треки в относительно высоком битрейте (даже Mp3 320, не говоря о всяких флаках) на aptX и AAC звучат чутка получше, чем на SBC. Боле богатая проработка частот там, где обили инструментала, или типа того. Но критичной разницы не видел.
1. Anrikigai
  19.12.2018 16:29
  #19523158
  Может быть по микрофонной части Bluetooth гарнитур подскажете?
  То, что на i7s TWS собеседник сразу ругается, что плохо слышно — это ожидаемо.
  Но есть еще парочка более дорогих. Мне на них слышно получше, но собеседники все равно недовольны :(
  Мне бы как раз не для музыки, а для разговора. Можно даже «одноухие». В свое время был Plantronics Voyager, но, честно говоря, даже его микрофон был скорее «приемлемым», чем хорошим.
  1. ns3230
    19.12.2018 16:45
    #19523290
    А вот тут увы. Никогда в приоритет не ставил разговоры, поэтому все, что держал в руках — не без недостатка в этом плане. У одних микрофон на шнурке далековато (как у тех же KZ BTE), из-за чего хуже слышно, у других — наоборот, у самого уха и слабый (как у i7s или прочих недорогих полностью беспроводных).
    
    Anrikigai
    19.12.2018 17:21
    #19523534
    Ну на KZ BTE микрофон вполне можно во время разговора и поближе ко рту подносить, это меня устроило бы. Беда в том, что в моих X3 Bluetooth wireless headphones Sport Metal Magnetic Sweatproof Earpiece такого же форм-фактора такой трюк не помогает почему-то.
    Пользуюсь старыми отстойно китайскими за $6, у которых большая часть в правом ухе и маленький второй наушничек на тонком проводке. Вот через наушничек слушаю, а большую часть с микрофоном у рта держу. Остальные все хуже, как ни странно…
    
    Кстати, если уж на то пошло. Чем можно записать на Андроиде звук с такой гарниутры? Как ни удивительно, ни один из диктофонов, что я смотрел, не смог переключиться на BT. Единственное, что нашел с подобной настройкой, это Cinema FV-5 для записи видео. Вот там можно явно BT микрофон выбрать.
    
    ns3230
    19.12.2018 17:51
    #19523702
    Чем можно записать на Андроиде звук с такой гарниутры?
    
    На стоковом? Даже не знаю. А какая версия? У меня Xiaomi, на MIUI 10 звук с любой гарнитуры (и входящий, и исходящий) штатными инструментами нормально пишется.

Gordon01
19.12.2018 09:36
#19520552
Если бы вы послушали LDAC, этой статьи бы не было.
Зачем в начале 2019 ещё раз писать о том, о чем уже сто раз написали?
1. VVizard
  19.12.2018 17:13
  #19523478
  Например в машине за 4 500 000 руб в 2019 году головное устройство не умеет LDAC по BT.
  1. Gordon01
    19.12.2018 18:33
    #19523914
    Машины — это зло в принципе. Мультимедиа системы в них — просто концентрат зла.
    Очень круто, когда в машине трехлетней давности уже чувствуешь себя в прошлом веке, так как нет iShit Play и прочего «необходимого» мусора.
    
    VVizard
    19.12.2018 18:42
    #19523958
    Примерно 1,5 часа в день я провожу в машине и слушаю музыку, увеличение битрейта SBC которое изначально проделал ValdikSS и описал в статье gjf, в моем случае позволило улучшить качество звука, не скажу что прям сильно но разницу на многих знакомых композициях можно услышать.
    При этом по кабелю через AUX звук хуже (возможно какие то особенности реализации AUX в моей мультимедиа системе).
    Так что тема эта очень интересная, полезная и актуальная.
    
    Gordon01
    19.12.2018 18:49
    #19523996
    Вы же понимаете, что если бы все было в порядке, то по проводу вы бы получали идеальный звук?
    Может, одновременно с зарядкой подключаете? Тогда будут помехи от земляной петли
    
    lonelymyp
    19.12.2018 21:26
    #19524562
    Идеальный звук в телефоне это большая редкость, так что даже имея провод, велика вероятность что по блютусу звук будет лучше.
    
    Gordon01
    19.12.2018 21:31
    #19524576
    На айфоне, к примеру — идеальный звук: kenrockwell.com/apple/iphone-6s-plus-audio-quality.htm
    У меня такое было на телефоне за 3000 рублей. К машине за 4,5 М не полагается нормальный телефон?

k4ir05
20.12.2018 09:32
#19526066
А что можете сказать по поводу кодека LHDC? Например, в Fiio BTR3 заявлена его поддержка. Но нигде больше его не встречал. Какая-то азиатская разработка?
1. gjf Автор
  20.12.2018 21:01
  #19530558
  Погуглил и нашёл вот это:
  www.hwa-lhdc.org/how-it-works
  gitlab.com/savitech-lhdc/hardware_interfaces
  ru.feasywifi.com/news/huawei-launched-hwa-hd-bluetooth-technology-wi-17580193.html
  
  Очень похоже на то, что Huawei s Savitech решили сделать свой LDAC с преферансом и блудницами.
  Об LDAC написал. Не думаю, что здесь сильно отличается. Разве что акустики с LDHC вообще ёк.

nae
20.12.2018 10:31
#19526362
Со вводом повсеместной поддержки пятимегабитного блютуса тема потеряет актуальность :)
1. gjf Автор
  20.12.2018 10:38
  #19526392
  В Bluetooth 5 подняли скорость, но только для данных. Для звука всё осталось по-старому.

Беспроводные технологии передачи звука на базе Bluetooth: что же лучше? +32

Введение

Качество

Практические и очень субъективные итоги

Практика: исправляем то, что можно исправить

Часть 1. Включаем aptX

Часть 2. Повышаем битрейт SBC

Заключение

Комментарии (65)

gjf Автор

gjf Автор

gjf Автор

gjf Автор

gjf Автор

gjf Автор

gjf Автор

gjf Автор

gjf Автор

gjf Автор

gjf Автор