Замена PulseAudio уже почти здесь

Поверю. Удалял отключал на Ubuntu 14.04, ибо не смог добиться нормальной работы.

Звук будет, но многое отвалится по ГУЮ.

интеграцией с Flatpak

Я даже не знаю, что хуже - pulseaudio или flatpak

Видишь ли, у этого нового сервера есть фундаментальный дефект: его написал не поцтер.

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

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

Приложения для ALSA итак прозрачно и прекрасно работают с Jack даже без пересборки.

Через конфиг альсы. Не совсем динамическое получается, но можно сверху jack навернуть, и тогда всё будет отлично.

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

Проигрывание звука - это вполне стандартная задача.

Наркоман и ССЗБ тот звукач, который будет использовать онтопик «в продуктиве».

Ты опять признал себя идиотом. Так держать!

Ну некоторые в экселе рисуют картины и пишут игры в 1C, почему кому-нибудь не завести в графическую библиотеку работу с сетью и вот этим всем.

Ты опять не принял таблетки?

Мне лицензия не нравится. И то, что это опять всё будет ломать и пердеть и блюпуп опять отвалится... фу как надоело...

На Wayland переходит софт, а не дистрибутивы. Некоторый софт на Wayland не перейдёт никогда, потому что идеологически с ним не совместим. Например, из X.Org нельзя выкинуть X11 и заменить его на Wayland.

Ну в принципе вы правы.

Только хочу заметить, что X11 - это скорее протокол как и wayland, xorg одна из реализаций X11. X.Org - это просто фонд для созданный для разработки X11 сервера. Соответственно c выкинуть X11 из X.org - это вы загнули. И вроде как freedesktop реализует оба этих протокола, причем разработчики там часто работают сразу как над x11, так и над wayland.

Приложения для ALSA итак прозрачно и прекрасно работают с Jack даже без пересборки.

Ээээ это как так? У меня они либо блокируют девайс, либо не могут получить к нему доступ, потому, что там сидит jackd. Собственно из-за этого приходится подгружать модуль с loop sound device и подключать его к джеку.

У PulseAudio наоборот, цель — максимизировать задержки: накормить аудиоадаптер двумя секундами данных, чтобы он не беспокоил основной CPU. Как они это вместе смешивать собрались?

Никак. «Накормить аудиоадаптер двумя секундами данных, чтобы он не беспокоил основной CPU» - это ложная экономия, от которой PipeWire отказался.

А ложная она, поскольку не имеет смысла без возможности сказать «ой, я имел в виду совсем другое, замени вот эти посланные, но не проигранные две секунды на другой звук». PulseAudio говорит «ой» (а по-научному - отматывает буфер назад) каждый раз, когда изменяется громкость или когда при проигрывании чего-нибудь появляется еще и звук системного уведомления. Ведь иначе это самое изменение громкости или системное уведомление проиграется через две секунды. Вот только сделать такую отмотку корректно у PulseAudio уже десять лет, как не получается, так как задача, оказывается, очень сложная, если есть хоть какая-то обработка звука. Тот же ресемплинг (https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/163) или, что еще хуже, кодирование для пересылки по bluetooth. Даже запись с monitor source при этом получается неправильная. И еще новые звуковые карты (в том числе встроенные от Intel) агрессивно кешируют содержимое своего буфера, т.е. отмотать там не всегда получится.

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

Вот моя презентация на эту тему: http://lac.linuxaudio.org/2015/download/rewind-slides.pdf http://lac.linuxaudio.org/2015/video.php?id=8

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

УМВР

Собственно из-за этого приходится подгружать модуль с loop sound device и подключать его к джеку.

У ALSA в комплекте есть плагин для работы с Jack. Каждое приложение в отдельный звуковой порт заворачивается автоматически: https://wiki.archlinux.org/index.php/JACK_Audio_Connection_Kit#Playing_nice_w...

Соответственно, даже dmix не нужно ничего микшировать.

А вот так

https://9to5mac.com/2019/02/06/adobe-premiere-cc/

на этом сервере можно или опять прыщи ни о чем, мак вперде?

Оно же будет работать без глюков, - это не интересно.

У ALSA в комплекте есть плагин для работы с Jack. Каждое приложение в отдельный звуковой порт заворачивается автоматически: https://wiki.archlinux.org/index.php/JACK_Audio_Connection_Kit#Playing_nice_w...

Пробовал wine что-то там не успевает и звук отваливается... Поэтому и пришлось возится с девайсом.

хм... может, стоит потыкать палочкой на досуге.

пробежалась по их гиту - код на C, они позаботились о независимости от ненужнод (опционально). минус в том, что сборка с пистоном. впрочем, она легко заменяется на autotools, ибо код невелик.

Звучит интересно. Значит ли это, что все фризы и щелчки пропадут как класс?

Спасибо за ссылки. Интересное чтиво.

им просто показалось, что у pulseaudio мало фич (нет видео) и они решили сделать комбайн еще больше. а получится ли у них low latency или нет, это уже вопрос второй.

Чем это лучше sndiod из OpenBSD (его уже портировали в лялех)?

ничем не лучше, т.к. в точности, как и sndio, его не поддерживает ни одно приложение. мало что-то такое крутое написать, надо еще чтобы другие озаботились через это звук играть.

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

спасибо за пояснения

редхата... их же gstreamer

Чего?

того. gstreamer под крышей gnome foundation, кто у нас главный любитель гнома мы знаем. gstreamer входит в redhat base channel и на него залинкованы все приложения.

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

ничем не лучше, т.к. в точности, как и sndio, его не поддерживает ни одно приложение.

Чо, правда ни одно? А в openbsd звук через святой дух работает?

я стесняюсь спросить... какой звук издает openbsd?

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

а ffmpeg - отличный инструмент. он умеет практически всё и там ничего лишнего. но он никак не относится к мультимедии прослоек вроде jackd. это просто параллельные вещи.

я смотрел код. gstreamer - это редхат core tech, входит в их стек разработки, поэтому ес-но там все строится на gstreamer. так что этот балет мне напоминает историю с gnome2 - за 10 лет только чуть-чуть привели в рабочее состояние и на тебе... все заново.

ну, если так, то тогда это ненужно. зависимость от таких мегатрупов - это нехорошо.

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

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

вам программистам виднее насчет переписать, но только переписать там и можно

src/gst/gstpipewiresrc.c:

gst_pipewire_src_change_state (GstElement * element, GstStateChange transition);
gst_pipewire_src_set_property (GObject * object, guint prop_id,
gst_pipewire_src_get_property (GObject * object, guint prop_id,
gst_pipewire_src_provide_clock (GstElement * elem)
gst_pipewire_src_finalize (GObject * object)
gst_pipewire_src_class_init (GstPipeWireSrcClass * klass)
gst_pipewire_src_init (GstPipeWireSrc * src)
gst_pipewire_src_stream_start (GstPipeWireSrc *pwsrc)
gst_pipewire_src_negotiate (GstBaseSrc * basesrc)
gst_pipewire_src_unlock (GstBaseSrc * basesrc)
gst_pipewire_src_unlock_stop (GstBaseSrc * basesrc)
gst_pipewire_src_event (GstBaseSrc * src, GstEvent * event)
gst_pipewire_src_query (GstBaseSrc * src, GstQuery * query)
gst_pipewire_src_create (GstPushSrc * psrc, GstBuffer ** buffer)
gst_pipewire_src_start (GstBaseSrc * basesrc)
gst_pipewire_src_stop (GstBaseSrc * basesrc)
gst_pipewire_src_open (GstPipeWireSrc * pwsrc)
gst_pipewire_src_close (GstPipeWireSrc * pwsrc)
gst_pipewire_src_change_state (GstElement * element, GstStateChange transition)

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

ну, может быть, может быть. но копирайты тоже кое-что говорят:

./src/daemon/daemon-config.c: * Copyright (C) 2016 Axis Communications <dev-gstreamer@axis.com>
./src/daemon/daemon-config.h: * Copyright (C) 2016 Axis Communications <dev-gstreamer@axis.com>
./src/modules/spa/module-node.c: * Copyright (C) 2016 Axis Communications <dev-gstreamer@axis.com>
./src/modules/spa/module-monitor.c: * Copyright (C) 2016 Axis Communications <dev-gstreamer@axis.com>
./src/pipewire/module.c: * Copyright (C) 2016 Axis Communications <dev-gstreamer@axis.com>
./src/pipewire/command.c: * Copyright (C) 2016 Axis Communications <dev-gstreamer@axis.com>
./src/pipewire/module.h: * Copyright (C) 2016 Axis Communications <dev-gstreamer@axis.com>
./src/pipewire/command.h: * Copyright (C) 2016 Axis Communications <dev-gstreamer@axis.com>

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

а гномятина вся тащится всей кучей всегда: запутанность архитектуры и нарушения KISS сказываются.

Как так то? Нас же всегда «эксперты» уверяли что ради одного КДЕ приложения весь кде ставится а гном вон он модульный!

смысла особо нет. та же фряха, которая страдает от systemd-империализма поставит этот gstreamer со всем остальным гномовским барахлом.:-/ короче, ситуация простая кто девушку, пардон, ужинает... тот и тащит все ее барахло. делают редхатовцы, потому что у них не получилось исправить продукт от поттеринга(pulseaudio, потеринг любит из себя архитектора строить и в этом больше всего и косячит), они сделают это со своими технологиями. что-то будет лучше, что-то криво по-новому. в конце концов аудио/video для них не главное. я вон недавно фряху настроил - то же самое. хорошо, конечно, что они такие тормоза, система более логичная, но вот горячие клавиши для клавы пришлось правкой кода добавлять.

может, это про systemd было))

я бегло посмотрела сборки - там gstreamer - опция. не знаю, тащится ли ещё где-то гномятина, но маловероятно. по идее, там ничего этого просто не нужно.

а что фряха страдает? оно же выпиливается на раз. там единственное место, где сложно выпиливать - udev. но и то можно. есть eudev.

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

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

ну из-за этого выпиливания у них гном 2016 года. выдержанный так сказать) я так понял во фряхе, если некому чем-то заниматься, они спокойно тебе и версию 2012 года предложат. лишь бы формально компилятор собирал:) поттер же сказал, что все, кроме линукса irrelevant. ну вот они помаялись и плюнули, похоже. правда я ничего из гном3 не пытался ставить. возможно, чего-то не знаю)

у гнома3 есть одна хорошая и незаменивая фишка. они начали делать поддержку icc профайлов для фотографов и прочих. реализовали ее в colord и этот шаг - это шаг из 80-90х. но вот поди ж ты... опять ее использует 1 application. короче, не при нашей жизни сделают они из линукса полнофункциональный десктоп. а десктоп админа и программера и так давно работает.

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

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

я даже не знаю, что такое icc-файлы. я гном3 считаю отстоем из отстоев.

насчёт старого и «доброго» - это вопрос. Linux очень сильно развился со времён 2.18 или даже с 3.32. и сам он развивается вполне себе неплохо (ну, за исключением некоторых неудачных с моей точки зрения решений вроде разрешения браузерам прямого доступа к памяти). если взять старое говно мамонта вроде соляры - там прямо ощущается вся древность и недоразвитость. причём очень сильно. как в плане юзерского использования, так и в программистском смысле. в хэдерах системы просто отсутствуют многие нужные вещи. и голый позикс выглядит страшно.

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

ну это то, что у всех уже давно есть. как только начинаешь манипулировать картинками, эта штука нужна также, как ... верно настроенный system time для админа.

Color management is a very crucial aspect of any activities covering graphics and photography. Color management is needed to achive a predictable and consistent color reproduction throughout the production chain from the input device (e.g. a camera) to the display for working on the image and up to the desired output device (e.g. printing).