PulseAudio и JACK

Предлагаем вашему вниманию перевод статьи Леннарта Пёттеринга “PulseAudio and Jack”.

На конференции http://lac.linuxaudio.org/2010/ в Утрехте я кое-что понял: даже многие специалисты по профессиональному звуку не уверены, в чём именно заключается разница между JACK и PulseAudio, почему эти две системы не конкурируют, почему не являются взаимозаменяемыми и почему попытка объединить их (как минимум в краткосрочной перспективе) скорее всего бессмысленна. Иными словами, почему на миллионах телефонов работает PulseAudio, а не JACK, и почему PulseAudio не используется в студиях звукозаписи.

Чтобы прояснить ситуацию, я постараюсь объяснить причину разделения между этими двумя системами, и почему это разделение совсем необязательно плохо. Текст можно считать литературной версией (части) моих слайдов для LAC, так что если вы были на этой конференции, вряд ли вы узнаете что-то новое. Надеюсь, что информация всё же окажется интересной.

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

Для начала давайте сравним основные требования, предъявляемые к этим звуковым системам:

Потребительский звук (т.е. PulseAudio)	Профессиональный звук (т.е. JACK)
Снижение энергопотребления является решающим фактором, большинство систем работает от аккумуляторов (ноутбуки, телефоны).	Энергопотребление обычно не является проблемой, всегда есть запитывание от розетки.
Должна поддерживать достаточно малые задержки отклика, достаточные для игр и телефонии. Есть применение и для больших задержек отклика — кино, музыка (двухсекундной задержки бывает достаточно)	Минимальная задержка отклика является решающим фактором.
Система в высшей степени динамична, поскольку то и дело запускаются и закрываются приложения, подключается и отключается аппаратное обеспечение.	Во время работы конфигурация системы как правило статична.
Пользователь как правило не очень хорошо разбирается в используемых технологиях.[1]	Пользователь как правило является профессионалом, разбирающимся в цифровом звуке и компьютерах.
Пользователь не обязательно администрирует компьютер и может иметь ограниченный доступ к её управлению.	Пользователь обычно администрирует свои компьютеры и имеет к системе доступ с правами суперпользователя.
Получение звука — всего лишь одна из многих задач системы, часто решаемая в фоновом режиме.	Работа со звуком является основной задачей при работе с системой.
У аппаратного обеспечения скорее ограниченные ресурсы, оно чаще фиговенькое и дешёвое.	Аппаратное обеспечение качественное, дорогое и мощное.

Разумеется, не всё настолько чёрно-белое, есть и случаи комбинирования этих условий.

Из приведённой выше таблицы можно сделать несколько выводов:

• Потребительская звуковая система должна поддерживать  работу в режимах как малой, так и большой задержки отклика. Поскольку малая задержка отклика означает высокий расход ЦП, а следовательно — высокое потребление энергии ^[2] (по Гейзенбергу), система должна работать с максимально возможной, но минимально необходимой задержкой отклика.
• Поскольку требования к потребительской системе динамичны, задержка отклика также должна уметь меняться на лету. Таким образом планирование с помощью таймеров становится необходимостью, и как раз такой подход реализован в PulseAudio.
• Основным объектом оптимизации в системах для профессиональной работы со звуком является малая задержка отклика. Низким энергопотреблением, динамически меняющейся конфигурацией (непродолжительное выпадение сигнала при изменении тракта приемлемо) и дружелюбием к пользователю можно пожертвовать.
• Для работы с буфером большого размера существует нулевое копирование (zero-copy), которое позволяет понизить давление на кэш при работе с крупными блоками данных, поскольку стоимость передачи указателей заметно ниже стоимости передачи собственно данных (верно и обратное: когда блоки размером с указатель, передача указателей — бессмысленная трата времени).
• В системе с ограниченными ресурсами идеальный звуковой тракт без причины не трогает и не преобразовывает проходящие по нему данные. Поэтому важна встроенная поддержка типов сэмплов и режимов чередования как источника звука, так и «принимающей стороны».
• Потребительская система должна упрощать представление аппаратного обеспечения, скрывать его сложность: скрывать повторяющиеся элементы микшера или объединять их, не отказываясь от предоставляемых устройствами возможностей,  и расширять их в программном обеспечении так, чтобы одна и та же функциональность была доступна для всего аппаратного обеспечения. Напротив, система для производства контента не должна скрывать или упрощать функциональность аппаратного обеспечения.
• Потребительская система не должна терять сигнал, когда одно из клиентских приложений плохо себя ведёт, либо меняется конфигурация (с другой стороны, если это происходит в порядке исключения, ничего страшного в этом нет). Таким образом синхронный тракт не является рекомендуемым, клиентам необходимо передавать данные асинхронно.
• В профессиональной звуковой системе потеря сигнала во время реконфигурации приемлема, а вот во время работы — недопустима.
• В потребительской звуковой системе необходим компромисс применительно к расходуемым ресурсам, который при профессиональной работе со звуком вообще не стоит принимать в расчёт. В качестве примера: профессиональная звуковая система может делать memlock() с несущественными ограничениями, поскольку аппаратное обеспечение это позволяет (т.е. в компьютере достаточно оперативной памяти), а качество звука является наиболее значимым. Потребительская же звуковая система не может так поступить, поскольку подобный вызов делает память практически недоступной для других приложений, что приводит к повышенной нагрузке на раздел подкачки (swap). А поскольку качество звука не является главной целью при наличии ограниченных ресурсов, необходим иной путь.

JACK был спроектирован для работы с малой задержкой отклика, где рекомендуется синхронное исполнение, при котором хулиганящий клиент может закупорить весь тракт. Изменения в тракте или задержке отклика обычно так или иначе приводят к потерям сигнала, поскольку реконфигурируется весь звуковой тракт — от аппаратного обеспечения до разнообразных клиентов. JACK поддерживает только сэмплы в формате FLOAT32 и нечередующиеся звуковые каналы (что хорошо). JACK не использует буферы нулевого копирования и не пытается упростить для пользователя работу с аппаратным микшером.

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

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

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

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

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

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

Так что же дальше? Я считаю, что вместо слияния надо сконцентрироваться на взаимодействии: научить PulseAudio выходить сразу как только JACK нужно получить доступ к устройству, а также сделать PulseAudio обычным клиентом JACK, мирно сосуществующим с ним. Таким образом пользователь получит возможность использовать потоки от PulseAudio, но при этом как правило не будет получать их в тракте по умолчанию.

Первая часть этого плана уже реализована: JACK2 и PulseAudio не дерутся за звуковое устройство, а вежливо передают его друг другу из рук в руки. JACK получает приоритет, а PulseAudio наслаждается почётным вторым местом.

Вторую часть плана ещё предстоит реализовать: вам всё ещё нужно вручную подключать PulseAudio к JACK, если в тракте нужны потоки PulseAudio.

При условии реализации обеих частей плана запуск JACK будет приводить к замене движка PulseAudio на движок JACK при сохранении полной совместимости с клиентами PulseAudio.

Вот, пожалуй, и всё, что я могу сказать по поводу JACK и PulseAudio.

А, вот ещё один момент: на некоторых новостных сайтах пишут, что у PulseAudio не такая уж блестящая репутация среди тех членов сообщества, кто пользуется Ubuntu и прочими дистрибутивами, взявшими систему на вооружение столь рано.

Что ж, придётся заявить открыто: может быть они и допустили пару ошибок при упаковке PulseAudio, на что я публично указывал (может быть и не слишком дружелюбно), но я уверен, что они сделали это своевременно.

Почему? Мы имеем дело с типичной проблемой курицы и яйца. Если система не используется в дистрибутивах, она не тестируется, вследствие чего при обнаружении ошибок никто не продавливает необходимость их исправления. Это касается как самой PulseAudio, так и прослоек вверху и внизу.

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

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

Иными словами, если функциональность реализована верно, и по результатам тестирования в узком кругу пользователей всё работает корректно, рано или поздно необходимо впихнуть систему в дистрибутивы, даже если при этом что-то сломается. В противном случае вы навсегда увязнете в разработке. Так что, на мой взгляд, создатели Ubuntu правильно поступили, интегрировав PulseAudio.

Сноски

[1] К примеру, потребители чаще не имеют никакого представления о децибелах и считают, что уровень громкости должен быть в процентах, которые для звука являются самой бессмысленной единицей измерения. Это докатилось даже до проектов вроде VLC и Amarok, где регуляторы громкости линейны (совершенно ужасная идея).

[2] На случай, если вам интересно, почему так: если задержка отклика маленькая, размер буфера должен быть меньше. Чем меньше размер буферов, тем чаще за одно и то же время воспроизведения центральный процессор должен «проснуться» и заполнить их. Так что нагрузка на процессор растёт, а полезная нагрузка — уменьшается. Ну и кроме того, частые пробуждения не дают процессору засыпать надолго, в то время как именно состояние бездействия является для современных процессоров основным способом экономии электроэнергии.

---

Примечание от переводчика: видеозапись выступления Леннарта на конференции Linux Audio Conference 2010 можно скачать по этой ссылке (199МБ, 60 минут).