Arial Georgia Tahoma Times New Roman Verdana

Особенности обработки аудио в ОС Android

И как с ними бороться

Подумайте, какие ассоциации вызывает у вас операционная система Google Android? Наверняка, одной из первых в голове всплыла «распространенность», «популярность». Или, при подобающем настроении, такое словосочетание как «зоопарк устройств». Что и говорить, выбор в пользу Android уже давным-давно сделали почти все известные разработчики мобильных гаджетов.

В крупных компаниях этот шаг знаменует собой начало большого пути для подразделения R&D (Research and Development). Ведь базовые возможности Android (по крайней мере, до релиза Lollipop) были весьма скромны и могли устроить только завсегдатаев XDA Developers, которые все необходимое и сами могут дописать. В поисках примеров можно даже не уходить в дебри Android. Скажем, аппараты с поддержкой нескольких SIM-карт уже давно стали самым обычным явлением на рынке. А API для работы с ними был официально добавлен только в Google Android 5.1.

Сегодня мы подробно рассмотрим еще одну сторону ОС, которой разработчики Google Android не уделяют достойного внимания — работу со звуком. Зачем, в принципе, нужен звук на телефоне? В первую очередь, чтобы воспроизводить звонок. С этой задачей мобильные устройства справляться уже научились. Было бы здорово также вставить какой-нибудь аудиоплеер... и здесь компания Google без особых раздумий перекладывает все на производителей устройств. Беспроводное проигрывание через Bluetooth или динамики мобильных устройств зависит от ряда дополнительных факторов, требующих отдельного изучения, поэтому в данной статье мы рассмотрим, как обстоят дела с воспроизведением аудио исключительно через разъем для наушников.

До выхода Android L операционная система поддерживала «из коробки» только PCM-аудио с частотой дискретизации 44,1 или 48 кГц. К этому общему знаменателю по умолчанию приводится весь пропускаемый через систему аудиопоток. Исправление ситуации проходит на уровне конкретных производителей, которые устанавливают собственные ЦАП и пишут для них софт. Это могут позволить себе лишь крупные компании. Приобретая такое недешевое устройство как смартфон, хочется услышать адекватный по стоимости аудиочип, но на сегодняшний день это является скорее исключением из правил — большинство моделей ограничиваются лишь тем, что включено в однокристальную систему. А это значит, что воспроизведение происходит с принудительной конвертацией звука в формат, описанный в начале абзаца.

Любой, кто хотя бы немного знаком с обработкой звука, знает, что всякое препятствие на его пути чревато самыми тяжелыми последствиями. При желании проследить всю обработку звука в ОС Android можно через исходный код. Уже при поверхностном изучении настороженность вызывают следующие моменты:

1. Для принудительной конвертации в нативный формат применяются как минимум целых три конвертера — в audioflinger, speex и webrtc. Здесь никакого прогресса не наблюдается с самых ранних версий, Google лишь исправляет баги.
2. Слишком высокий тайминг в аудиосервере Android (audioflinger/libstagefright) при большом числе потоков.
3. Программная регулировка громкости — критичный для аудиофилов аспект, с которым, увы, ничего не поделаешь в принципе.
4. Колоссальные проблемы с поддержкой ALSA-драйверов (Advanced Linux Sound Architecture). Этот вопрос решается на уровне производителей устройств. Некоторые из них уже предлагают удачные решения, например, Sony и HTC.

Помимо R&D-отделов больших компаний, над улучшением звука Android активно работают энтузиасты, разрешающие порой чуть ли не безвыходные проблемы. Плоды этих титанических трудов можно оценить на пресловутом XDA Developers.

Здесь работает общее правило: чем ниже уровень, на котором производятся улучшения, тем эффективней будет результат. Материнские платы компьютеров легко вмещают всякие разновидности «high definition audio», способные удовлетворить не очень щепетильного пользователя. Что же касается современных мобильных устройств, то их размеры создают для реализации качественного звука гораздо более серьезные ограничения.

Тем не менее, прогресс в звуковой составляющей современных смартфонов очевиден. Как это ни удивительно, даже чипсетные кодеки порой играют неплохо, например, ЦАП Hexagon, устанавливаемые в SoC Qualcomm Snapdragon. Что касается однокристальных систем, менее выдающихся в плане звука (модели Samsung Exynos, Mediatek MTK), то их производители сейчас нередко устанавливают сторонние ЦАП. К сожалению, при таком подходе обычно игнорируется сопроводительная документация, что приводит к затруднениям на более высоких уровнях.

А выше «железа» у нас прописано ядро Linux — база, на которой функционирует ОС Android. Здесь находится все, что обеспечивает работу аппаратной начинки. Конкретно за звук отвечает ALSA — Advanced Linux Sound Architecture. Пионером в реализации ALSA стала компания Samsung, а вообще в ранних устройствах на базе Android эта архитектура еще не поддерживалась, поскольку сама Google еще не пришла к необходимости единообразия на данном уровне разработки.

Сама по себе архитектура ALSA является весьма оригинальной, что отчасти объясняет проблема в создании низкоуровневого ПО. Даже на написание даже простого драйвера требуется много времени. К тому же, в отличие от десктопных систем, у смартфонов есть своя специфика. Поскольку мы имеем дело с телефоном, обязательна реализация голосовой связи. Кроме того, требуется грамотное управление питанием — об автономной работе Android-устройств лишний раз и говорить нечего. Наконец, учитывая ограниченные ресурсы прикладного ЦП, встает вопрос о декодировании популярных форматов другими аппаратными средствами.

Типичный сценарий работы над ALSA-драйверами сегодня выглядит следующим образом. Поставщик SoC или кодека предоставляет производителю устройства некую «рыбу» в комплекте с многотомной документацией, при виде которой у Linux-сообщества потекли бы слюнки. Но работникам R&D-отделов производителя такой энтузиазм, мягко говоря, не свойственен. В результате чего пользователи получают ПО, где взамен реализованных возможностей железа предлагаются лишь бесчисленные баги и вообще полнейшие нелепости.

В качестве примера можно привести компанию Qualcomm, которая никакой документацией с аудиторией не делится. Но хотя бы выкладывает исходный код драйверов на своем сайте codeaurora.org. С другими поставщиками чипов ситуация тоже непростая. Даже такие либеральные в этом плане компании как Texas Instruments или Intel, публикующие все спецификации своих устройств еще до начала поставок, иной раз хранят молчание, когда речь заходит о звуке.

Что касаются производителей «второго эшелона» (как правило, многочисленных и малоизвестных компаний из Китая), то в соответствии с лицензией GPL они не обнародуют исходный код ядра вообще. С этической точки зрения выглядит это весьма скверно: на основе открытого кода Linux создается по сути закрытый, засекреченный продукт.

Как же свести весь этот «зоопарк» к общему знаменателю, чтобы любой обладатель Android-устройства мог получить качественный звук? Интерфейс ALSA-драйверов един, и, если доступны их исходные файлы, можно попытаться самостоятельно улучшить качество звука, чтобы использовать возможности устройства на 100%.

Поскольку взаимодействие осуществляется на уровне ядра, для всех нововведений потребуется наличие рут-доступа. Это позволит обойти верхние уровни аудиосистемы Android и взаимодействовать с ALSA-драйверами напрямую. Что и делает программа, которую мы задействуем для сравнительного тестирования аудиотрактов.