The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Новая версия музыкального проигрывателя DeaDBeeF 1.8.8, opennews (??), 05-Авг-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


140. "Новая версия музыкального проигрывателя DeaDBeeF 1.8.8"  +/
Сообщение от Stax (ok), 05-Авг-21, 16:57 
> - официальная поддержка pipewire (у DeaDBeeF поддержка тоже есть, но модуль не официальный)

А какая там поддержка требуется? Я думал.. там полная совместимость с пульсом в плане звука, если есть вывод через пульс, то нативно и в pipewire будет.

Ответить | Правка | Наверх | Cообщить модератору

144. "Новая версия музыкального проигрывателя DeaDBeeF 1.8.8"  +/
Сообщение от Anonimous (?), 05-Авг-21, 17:26 
Смотри, если модуль вывода указал пульсу или альсу, то pipewire сначала ретранслирует запросы для пульсы или альсы в запросы для pipewire и только потом pipewire работает с звуковым потоком. Оно не сказать что б критично, просто лично я предпочитаю не ретранслировать запросы там где этого можно не делать и взаимодействовать напрямую.
Также прямо сейчас такой подход полностью решает проблемы типа:
https://github.com/DeaDBeeF-Player/deadbeef/issues/2574
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/652
Ответить | Правка | Наверх | Cообщить модератору

167. "Новая версия музыкального проигрывателя DeaDBeeF 1.8.8"  +/
Сообщение от Stax (ok), 05-Авг-21, 21:02 
> Смотри, если модуль вывода указал пульсу или альсу, то pipewire сначала ретранслирует
> запросы для пульсы или альсы в запросы для pipewire и только
> потом pipewire работает с звуковым потоком. Оно не сказать что б
> критично, просто лично я предпочитаю не ретранслировать запросы там где этого
> можно не делать и взаимодействовать напрямую.
> Также прямо сейчас такой подход полностью решает проблемы типа:
> https://github.com/DeaDBeeF-Player/deadbeef/issues/2574
> https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/652

Эмм. Зачем мешать в одну кучу пульсу и альсу?

Понятно что при выводе в альсу там не очень хорошая прослойка. Равно как и alsa-> pulse. Просто by design, слишком разные API и разные подходы, и многие старые приложения делали через API ALSA то, что не очень хорошо совместимо с прослойкой.

Прослойка pulse->pipewire очень простая и для целей воспроизведения аудио никаких проблем не вызывающая. Говорить, что она плоха только потому, что там что-то не напрямую странно - так можно договорться и libasound выкинуть и писать напрямую в /dev/*, чтобы и alsalib "исключить".

Оба этих бага вызваны тем, что некие ССЗБ выводят через alsa. Если бы они не пытались делать странное и выводили в pipewire через API pulseaudio, уверен никаких бы проблем не было вообще (при условии корректной реализации этого API в самом deadbeef)

Ответить | Правка | Наверх | Cообщить модератору

179. "Новая версия музыкального проигрывателя DeaDBeeF 1.8.8"  +/
Сообщение от Anonimous (?), 05-Авг-21, 23:02 
>> Эмм. Зачем мешать в одну кучу пульсу и альсу?

потому что дефолтно и будет работать одинаково.
Если ты в плеере указал альсу, то поток пойдет
app -> pipewire-alsa -> pipewire -> ALSA KERNEL API
app -> pipewire-pulse -> pipewire -> ALSA KERNEL API

все будет работать и так, но лично мне больше нравится схема

app -> pipewire -> ALSA KERNEL API
При такой схеме я не завишу от того насколько качественно сделанна прослойка pipewire-alsa или pipewire-pulse. Основное назначение эти прослоек - в первую очередь обеспечить совместимость для приложений которые еще не научились работать без лишней прослойки.
И я не говорил что - это работает плохо (хотя латенси точно будет выше), я сказал что "я предпочитаю не ретранслировать запросы там где этого можно не делать и взаимодействовать напрямую".
Смысл немного другой в этих словах.

>> Оба этих бага вызваны тем, что некие ССЗБ выводят через alsa. Если бы они не пытались делать странное и выводили в pipewire через API pulseaudio, уверен никаких бы проблем не было вообще (при условии корректной реализации этого API в самом deadbeef)

Они не ССЗБ, т.к. знают что через pulseaudio сложно получить bit-perfect, поэтому и используют то что не искажает звук. Была бы пульса идеальной - не появился б jack и ее же разработчики не пилили б pipewire. У разных людей разные требования к одним и тем же вещам - кому то и с телефона с стандартной гарнитурой хороший звук, а кто-то покупает системы по стоимости квартиры, хотя цели вроде одинаковые.

Ответить | Правка | Наверх | Cообщить модератору

184. "Новая версия музыкального проигрывателя DeaDBeeF 1.8.8"  +/
Сообщение от Stax (ok), 06-Авг-21, 00:24 
>>> Эмм. Зачем мешать в одну кучу пульсу и альсу?
> потому что дефолтно и будет работать одинаково.

... это очевидно не так, потому что с 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 реально примирил оба лагеря).

Ответить | Правка | Наверх | Cообщить модератору

202. "Новая версия музыкального проигрывателя DeaDBeeF 1.8.8"  +/
Сообщение от Anonimous (?), 06-Авг-21, 10:54 
>>  это очевидно не так, потому что с ALSA случайно выстрелить себе в ногу на порядок проще, чем при использовании API pulseaudio

нет, судя по всему у тебя искаженное понимание как это работает... Можно хоть какие-то аргументы по этому поводу,а не просто "я так сказал"?

>> В силу того, что приложение ожидает от API ALSA и того, как устроен alsa-pulse, половина чистых ALSA приложений так никогда и не смогла нормально сосуществовать с пульсом, пока не появились нативная работа с pulse в аудио/видео проигрывателях, SDL и тп. Полагаю, ситуация с pipewire-alsa не сильно отличается. А вот с реализацией pipewire-pulse никаких заморочек нет вообще, она элементарная и там просто негде сделать так, чтобы не совсем работающее приложение ломалось.

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

>> Брррррр. Это совершенно разного уровня вещи же. И по реализации (один - модуль, подгружаемый из alsa, который в свою очередь является клиентом для pulseaudio либо pipewire), второй - сервер, умеющий протокол pulse аналогично настоящему pulseaudio

И как это влияет на взаимодействие по API?

>> bit-perfect это отдельная тема (и тем, кто точно знает, зачем он нужен - думаю, легко справится с этой сложностью). Зато HQ audio через pulse, с его поддержкой как нескольких частот сэмплирования с динамическим переключением, так и качественными реземплерами и тп по факту получить намного проще, чем через alsa.

Что такое bit-perfect вы вероятно также не разобрались.

>> Задачей получить bitperfect, где можно, а где нельзя - гарантированно минимальные (сильно ниже уровня слышимости)искажения

А вот и подтверждение того что написал выше. Спойлер, bitperfect - не допускает искажения вообще и измеряется еще до преобразования в аналог на ЦАПе.
Не совсем понимаю как вы профессионально занимались со звуком

>> И так продолжалось до - внезапно! появления pulseaudio. Который ранних версий не ругал только ленивый, но если к нему было приложить хотя бы 10% тех усилий, которые были нужны чтобы заставить Jack и alsa-jack работать, он становился просто прекрасен. И, к счастью, архитектура, в отличие от Jack, больше не позволяла кривому клиенту испортить весь звук: типичное кривое alsa приложение через alsa-pulse могло испортить только само себя, в случае кривой работы. Хотя я прекрасно понимаю, что другие задачи Jack никак не покрывались (и очень рад, если pipewire реально примирил оба лагеря).

Вы, наверное, единственный кто профессионально занимался аудио через пульсу;)
Пульса действительно решила много проблем, но она абсолютно не подходит для про задач, как минимум из-за значительно большего латенси, который не фиксится от слова "никак", поэтому все и мучались с Jack, не смотря на его проблемность.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру