LINUX.ORG.RU

PulseAudio 15.0

 


2

2

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

Код PulseAudio распространяется в рамках лицензии LGPL 2.1+ и может работать в Linux, Solaris, *BSD, macOS и Windows.

Ключевые улучшения PulseAudio 15.0:
  • Проделано много работы по поддержке Bluetooth: теперь есть новые A2DP-кодеки LDAC и AptX, встроенная поддержка профиля HFP (Hands-Free Profile) на базе кодека SBC, поддержка AVRCP Absolute Volume для программного управления громкостью подключённых устройств A2DP.
  • Реализована возможность сохранения профилей с настройками для звуковых карт, теперь состояние не сбрасывается после извлечения и подключения (например, полезно при переподключении HDMI).
  • С нуля переписан sink-модуль с реализацией виртуального эффекта объёмного звука module-virtual-surround-sink.
  • Прекращена поддержка инструментария Autotools (теперь используется Meson).
  • Добавлен новый API обмена сообщениями, упрощающий создание расширений базового API.
  • Предоставлена возможность размещения файлов конфигурации путей ALSA в домашнем каталоге пользователя.
  • Улучшена поддержка оборудования: SteelSeries Arctis 9, HP Thunderbolt Dock 120W G2, Behringer U-Phoria UMC22, OnePlus Type-C Bullets, Sennheiser GSX 1000/1200 PRO.
  • Улучшена поддержка FreeBSD. Теперь обработка горячего подключения и отсоединения звуковых карт работает корректно.

>>> Подробности

★★

Проверено: xaizek ()

Ответ на: комментарий от eternal_sorrow

Да, ресемплинг делается ровно один раз, на входе, на стороне клиента

Ты не понимаешь что мелешь. Пульсовые клиенты не делают ресемплинг на своей стороне. При работе с пайпвайром тоже. Это делает микшер.

James_Holden ()
Ответ на: комментарий от eternal_sorrow

Похоже на то. То есть pipewire-pulse подгоняет под основную глобальную частоту.

Худшие опасения оправдались, реализовать смену частоты при таком подходе скорее всего не получится. Мда…

James_Holden ()
Ответ на: комментарий от eternal_sorrow

Офигеть. Чем дальше в лес тем больше дров.

JACK applications will automatically use the buffer-size chosen by the server. You can force a maximum buffer size (latency) by setting the PIPEWIRE_LATENCY environment variable like so:

PIPEWIRE_LATENCY=128/48000 jack_simple_client Requests the jack_simple_client to run with a buffer of 128 or less samples.

То есть в режиме эмуляции джека оно даже не гарантирует заданого размера буфера. О у еть.

Кстати, никто не знает как сменить частоту дискретизации на заданную для jack приложений? Неужели только через конфиг и перезапуск пайпвайра?

James_Holden ()
Ответ на: комментарий от anonymous

Ты понимаешь, что любое смешивание аудиопотоков предполагает ресемплинг априори?

Ты с дуба рухнул? Серьезно? А если все потоки 44100, то тоже ресемплинг? Достали вы дошколята.

James_Holden ()
Ответ на: комментарий от James_Holden

А если начинается воспроизведение 44.1, потом подмешивается 48, а потом 44.1 прекращает воспроизводиться, а 48 продолжает дальше? В какой момент сервер должен переключить аудиокарту в 48?

khrundel ★★★ ()
Ответ на: комментарий от James_Holden

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

sadko4u ()
Ответ на: комментарий от sadko4u

Все проще.

На бытовом уровне есть поток 44100 и есть 48000. Любое бытовое железо поддерживает и то, и другое. Поэтому когда играют только потоки 44100, можно отрубать ресемплинг, что и делала пульса.

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

James_Holden ()
Ответ на: комментарий от James_Holden

Так а разве в PipeWire не так?

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

Ну а теперь, если прикинуть, какой геморрой для приложения будет, когда у него один выход - 44.1 kHz, второй выход - 88.2 kHz, а третий - вообще 192 kHz, а потоки гнать в эти выходы надо синхронно.

sadko4u ()
Ответ на: комментарий от sadko4u

Так а разве в PipeWire не так?

Да нет же. Автоматически переключаться должно. Вот я запустил музыку 44100 - без ресемплнига все пошло на аудиокарту. Запустил кино 48000 - сервер автоматически переключился на 48000 - без ресемплнига все пошло на аудиокарту. Запустил разные потоки - сервер автоматически врубает ресемплинг.

Так работает pulseaudio. В pipewire сервер всегда работает на одной частоте, заданной при запуске. Он не переключается.

Ну а теперь, если прикинуть, какой геморрой для приложения будет, когда у него один выход - 44.1 kHz, второй выход - 88.2 kHz, а третий - вообще 192 kHz, а потоки гнать в эти выходы надо синхронно.

А зачем так делать?

James_Holden ()
Ответ на: комментарий от James_Holden

А зачем так делать?

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

Кстати! Передискретизация так или иначе добавляет latency в сигнал, хотим мы этого или нет, но это всё из-за фильтров с линейной фазой, импульсная характеристика которых симметрична во времени.

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

sadko4u ()
Ответ на: комментарий от nioelumiijke

на одной частоте , которую поддерживает аудиокарта

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

James_Holden ()
Ответ на: комментарий от James_Holden

посмотрел , альса переключает на ту какую использует приложение. но оно одно(приложение). а если сервер будет переключать в зависимости от источников, какую выбрать, например играет аудиоплеер с 44100 и видеоплеер с 48000, допустим переключатся на аудиокарте 48000, а с аудиплеера делает ресемплинг 44100->48000. так ? или как оно должно правильно

nioelumiijke ()
Ответ на: комментарий от nioelumiijke

посмотрел , альса переключает на ту какую использует приложение

Да. Но в alsa тоже есть микшер dmix и раньше он все ресемплировал в 48000 по дефолту. Я уже лет 10 если использую alsa напрямую, то без dmix поэтому не знаю как сейчас. Напрямую - точно выбирается частота как у приложения.

Если с pulseaudio играет одно приложение - произойдет то же самое. Оно переключает (при правильной настройке конфига).

а если сервер будет переключать в зависимости от источников, какую выбрать, например играет аудиоплеер с 44100 и видеоплеер с 48000, допустим переключатся на аудиокарте 48000, а с аудиплеера делает ресемплинг 44100->48000. так ?

Да, так. В целом с pulseaudio так и делается. С jack - не делается.

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

Приложения jack - запрашивают у сервера, какая частота, и должны отдавать именно с такой частотой. Если не совпадает - то они должны сами ресемплировать под частоту сервера.

Получается, что pulseaudio и jack работают диаметрально противоположно. А pipewire должен поддерживать оба подхода. И сделали как проще - все работает как с jack. А pulseaudio приложения работают через прослойку-адаптер, которая при необходимости ресемплирует на частоту сервера.

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

Попытка запрыгнуть на два противоположных стула привела к вот такому.

James_Holden ()
Ответ на: комментарий от James_Holden

Попытка запрыгнуть на два противоположных стула привела к вот такому.

Я думаю, это вполне оправданно.

Если Pipewire претендует на работу сразу с несколькими аудиоустройствами одновременно (чего не может JACK без специальных адаптеров), то весь геморрой с ресемплингом под конкретный девайс становится просто очевидным. Поэтому, наверное, проще все девайсы с одним и тем же Sample Rate запустить, ну а для PRO Audio, наверное, просто даунсемплить поток на устройства, не поддерживающие повышенные частоты дискретизации.

Преимущества от этого в том, что не надо делать достаточно дорогую по CPU операцию ресемплинга по каждому чиху. Дорогую - потому что любой ресемплинг - это, по сути, свёртка сигнала с ядром фильтра Ланцоша, которую надо вычислять напрямую, а это O(n^2) вычислений.

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

sadko4u ()
Ответ на: комментарий от sadko4u

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

Я и предлагаю работать в рамках одной. Возможно вы меня не так поняли. Я хочу чтобы эта одна, единая в каждый момент времени частота дискретизации менялась под ситуацию. Если все хотят отдавать потоки 44100, или того проще - одно приложение воспроизводит поток 44100 - то почему бы не переключить частоту дискретизации сервера на 44100?

Возможно я не понятно пытаюсь выразить свою мысль.

Сейчас с pipewire ситуация такая, что сервер никого не спрашивает, какую частоту дискретизации приложение хочет. Он говорит - у меня вот такая, отдавайте на ней как хотите. Так работает и jack, и для PRO приложений это более чем оправданный подход, по тем самым причинам о которых вы пишите.

Но допустим у нас простой deadbeef, обычный потребительский плеер. Он хочет просто воспроизвести музыку, отдав поток как он есть. С alsa, pulseaudio он всегда так и делал. А потом сервер решал, что с этим потоком делать.

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

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

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

Раньше это противоречие между двумя вариантами решалось наличием двух не связанных звуковых серверов в линуксе. А теперь когда объединили что делать?

Я думаю что можно в API pipewire сделать два варианта ноды. Первый вариант всегда требует заливать поток с частоттой сервера. Второй вариант, назовем «ресемплирующая нода» - с любой частотой. Потом она подгоняет под частоту сервера.

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

Если хотя бы одна нода - обычная, это отключается и сервер работает на заданной в конфиге частоте.

Всякие браузеры, плееры будут создавать ресемплирующие ноды. Для них это полный аналог pulseaudio будет. Им это проще - не надо реализовывать ресемплинг внутри плеера.

PRO приложения будут создавать обычные ноды и все будет работать с ними как сейчас.

В неявном виде в pipewire сейчас такое разделение уже есть - все пульсовые приложения отдают что хотят, прослойка для pulseaudio api все ресемплирует. Это почти то же что я предлагаю. Только сейчас сервер никак не знает, с какой частотой отдает какое приложение. К нему приходит уже ресемплированный pipewire-pulse прослойкой поток.

James_Holden ()
Ответ на: комментарий от sadko4u

Тут еще вот какая проблема назревает.

Если мы заставили все пользовательские приложения иметь ресемплер внутри и самим подгонять поток под частоту сервера - то это же дикая чехарда.

Каждое приложение будет тянуть свои настройки и свой алгоритм ресемплинга. Невозможно будет понять какое приложение как и что делает в плане качества звука.

Поэтому ресемплер очень желательно иметь системный, с одной централизованной настройкой.

Во всех ОС так и было всегда. В линуксе с alsa и pulseaduio. В Windows тоже ресемплирует микшер. А PRO приложения используют отдельный API, который вообще блокирует пользовательские приложения.

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

James_Holden ()
Ответ на: комментарий от James_Holden

Если мы заставили все пользовательские приложения иметь ресемплер внутри и самим подгонять поток под частоту сервера - то это же дикая чехарда.

В этом плане я согласен. Мне кажется, что в этом случае PipeWire достаточно в спецификацию вставить что-то такое:

Если частота дискретизации отдаваемых данных не совпадает с частотой дискретизации сервера, то будет выполняться автоматический ресемплинг потока данных к частоте дискретизации сервера, но при этом не гарантируется соблюдение/синхронизация по latency.
sadko4u ()

Автоматическое переключение воспроизводящегося звука на подключенный bluetooth это шикарно. Раньше надо было на паузу ставить.

Sylvia ★★★★★ ()