>>> Эмм. Зачем мешать в одну кучу пульсу и альсу?
> потому что дефолтно и будет работать одинаково.... это очевидно не так, потому что с ALSA случайно выстрелить себе в ногу на порядок проще, чем при использовании API pulseaudio
> Если ты в плеере указал альсу, то поток пойдет
> app -> pipewire-alsa -> pipewire -> ALSA KERNEL API
> app -> pipewire-pulse -> pipewire -> ALSA KERNEL API
В силу того, что приложение ожидает от API ALSA и того, как устроен alsa-pulse, половина чистых ALSA приложений так никогда и не смогла нормально сосуществовать с пульсом, пока не появились нативная работа с pulse в аудио/видео проигрывателях, SDL и тп. Полагаю, ситуация с pipewire-alsa не сильно отличается. А вот с реализацией pipewire-pulse никаких заморочек нет вообще, она элементарная и там просто негде сделать так, чтобы не совсем работающее приложение ломалось.
> app -> pipewire -> ALSA KERNEL API
> При такой схеме я не завишу от того насколько качественно сделанна прослойка
> pipewire-alsa или pipewire-pulse. Основное назначение эти прослоек - в первую очередь
Брррррр. Это совершенно разного уровня вещи же. И по реализации (один - модуль, подгружаемый из alsa, который в свою очередь является клиентом для pulseaudio либо pipewire), второй - сервер, умеющий протокол pulse аналогично настоящему pulseaudio
> Они не ССЗБ, т.к. знают что через pulseaudio сложно получить bit-perfect, поэтому
> и используют то что не искажает звук. Была бы пульса идеальной
bit-perfect это отдельная тема (и тем, кто точно знает, зачем он нужен - думаю, легко справится с этой сложностью). Зато HQ audio через pulse, с его поддержкой как нескольких частот сэмплирования с динамическим переключением, так и качественными реземплерами и тп по факту получить намного проще, чем через alsa.
> - не появился б jack и ее же разработчики не пилили
> б pipewire. У разных людей разные требования к одним и тем
Эээ. А вот тут прошу не путать факты и порядок вещей :)
Задачей получить bitperfect, где можно, а где нельзя - гарантированно минимальные (сильно ниже уровня слышимости) искажения в линукс аудио я занимался лет 17 назад, если не больше. Я активно мучал и ALSA, и Jack, с разными приложениями и звуковыми картами. Очень многие карты в режимах выше 48/16 предъявляли специфичные требования: например audigy 2 zs имела 96/24 интерфейс, но он был строго однопоточным и 8-канальным - кроме специфических приложений, никто реальный не мог писать в hw: устройство с таким режимом. А Audiophile USB имела 24-битный режим в формате S32_BE, который опять же ни одно обычное приложение не умело. Так что без конвертации alsa (а это был треш) никак, ну либо Jack. И Jack был прекрасен в теории, но при попытке завернуть на него обычные приложения через alsa-jack все шло наперекосяк: его написали безнадежные идеалисты, считающие, что гарантированно, что приложение можно дергать по таймеру через коллбэк. Когда появлялись приложения, которые не давали такой гарантии, демон jack внутри себя сходил с ума и не мог больше микшировать другие приложения. Даже "типа музыкальные" приложения типа audacity (с кривым portaudio, который до версии 19 - что было сиииильно позже - очень не любил Jack) могли напакостить.
В общем, историй было много, проблем масса, тем не менее Jack был единственным, что хотя бы 95% времени работало. Но оставшиеся 5%.. И так продолжалось до - внезапно! появления pulseaudio. Который ранних версий не ругал только ленивый, но если к нему было приложить хотя бы 10% тех усилий, которые были нужны чтобы заставить Jack и alsa-jack работать, он становился просто прекрасен. И, к счастью, архитектура, в отличие от Jack, больше не позволяла кривому клиенту испортить весь звук: типичное кривое alsa приложение через alsa-pulse могло испортить только само себя, в случае кривой работы. Хотя я прекрасно понимаю, что другие задачи Jack никак не покрывались (и очень рад, если pipewire реально примирил оба лагеря).
