PulseAudio 15.0

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

пульс умеет отдавать на звуковуху разные частоты

флаг ему в руки

Не вали с больной головы на здоровую. Разбираться не хочешь ты. Тебе выше уже на пальцах объясняют, а ты шлангуешь.

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

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

Нет, при работе с пульсовыми клиентами ресемплинг делает pipewire-pulse.

Возможно, но откуда ты это взял?

как минимум потому что в pipewire-pulse.conf есть опция resample.quality.

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

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

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

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 приложений? Неужели только через конфиг и перезапуск пайпвайра?

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

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

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

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

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

в дебиане фокс работает и без шаманства с apulse, только в скайпе apulse нужен

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

вопрос не по теме, «eternal_sorrow» это реинкарнация фрактала? по уровню тупости вроде совпадает.

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

Все проще.

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

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

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

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

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

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

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

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

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

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

Кстати, видел у них в issues много сообщений от вас. А что там за проблемы, pipewire как-то ломало работу LSP?

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

А в итоге они пофиксили, на данный момент? А то я переехал на pipewire и будет плохо если ваши плагины отвалятся.

Вроде, оперативно поправили. Но я не проверял. У меня поддержка PipeWire только после 1.2.0 запланирована. И так много чего пилить к 1.2.0 надо.

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

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

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

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

Я понял о чем вы.

он может работает на одной частоте , которую поддерживает аудиокарта? тогда нормально.

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

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

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

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

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

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

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

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

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

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

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

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

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

спасибо за разьяснение. думаю, нужно настроить dmix

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да, тем более что так и сделано уже, но только для клиентов pulseaudio.

С другой стороны, можно сами аудиопотоки разделить на SOFT/HARD, и разрешить в SOFT гнать данные с другим sample rate, а HARD оставить для про аудио.

Ну да. Причем это желательно сделать пока все не повтыкали велосипедные ресемплеры по всем приложениям.

Это хороший повод сделать feature request на GitLab проекта.

МС уже кодеки по 0.99 продаёт

Угу. Блюпупа нет, шумодава нет, с вином не работает. Абалденно перегнали.

Блюпупа нет

есть

шумодава нет

тут хз. где твой фичреквест?

с вином не работает

как не работает? опять же, где багрепорт?

Не один. Но страдания есть, если 2 пользователя запущены в разных tty (по startx оболочки стартуют)

У меня бывает и больше 2, но в консольном режиме, (иксы ни разу так не запускал, нет причин), все работает.

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