LINUX.ORG.RU

Ardour, JACK и что делать с жопой под названием «звуковой стек Linux»

 ,


0

3

У меня тут вышло большое интервью с Полом Дэвисом (главный разработчик Ardour и бывший разработчик JACK) в двух частях.

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

Первая часть: http://libregraphicsworld.org/blog/entry/podcast-ep-002-paul-davis-on-the-deep-rewrite-of-ardour-daw

Вторая часть: http://libregraphicsworld.org/blog/entry/podcast-ep-003-paul-davis-on-fixing-big-linux-audio-issues

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

  • Некоторые пользователи не заинтересованы в ковырянии кода, они хотят чтоб как в Reaper – пишешь плагин на Lua, которые меняет вообще что угодно. Но в рипер Lua встроили явно на очень раннем этапе, сделать похожее в Ardour сейчас уже технологически сложно, поэтому покрытие API в привязках Lua хоть и расширяется, но ряд ограничений останется.

  • Последние несколько лет команда грохнула огромное количество времени на рефакторинг кода и переписывание реализации некоторых ключевых концепций в программе. На момент выпуска версии 6 остались два момента, которые отложены: более точная работа с перескоком между музыкальным временем и выборками (разработчики пока не договорились о ряде моментов в реализации) и встроенный лупинг. В остальном, переписанную часть можно больше не трогать ещё лет 10. Там есть, например, фундамент для запланированной возможности смены частоты сэмплирования на лету без перекодирования.

  • Пока шёл длительный рефакторинг, пользователи не особенно доставали разработчиков нытьем «ну когда же уже» и даже увеличили финансовую поддержку. Часть дополнительных средств Пол планирует бросить на улучшение документации и видеоуроки.

  • В последние годы проект понемногу уходит от применения GTK. Сейчас тулкит используется для всего нескольких вещей: упаковка виджетов на форме, файловые диалоги, текстовый ввод и виджет дерева (treeview). Остальное рисуется на Cairo. Если бы Пол начинал писать DAW сейчас, он бы выбрал готовый специализированный тулкит вроде JUCE. Переписывать виджет текстового ввода он, например, в принципе не возьмётся – масштаб такой работы часто недооценивается, там можно вообще концы отдать. А вот упаковка виджетов на constrained layout – в планах. На момент выхода второй части интервью уже есть ветка, где ведется эта работа.

  • Пол недавно упоминал, что общается с Мартином Кири (Tantacrul), который в прошлом году вышел на работу UX-дизайнером MuseScore (у Мартина популярный блог на ютубе, где он разбирает косяки в юзабилити программ для набора нот с применением фокус-групп пользователей). На прямой вопрос Пол ответил, что пока ничего конкретного сказать не может, но выразил восхищение работой Мартина и заметил, что нужно быть просто тупым, чтобы не хотеть слушать инсайты пользователей, которые работают с твоим софтом впервые.

  • Звуковой стек в Linux – кромешный ад, лучше CoreAudio в макоси пока ничего не придумано. Но в macOS несколько релизов назад часть функциональности убрали в user space демон. Примерно тот же принцип получается при сопряжении ALSA и PipeWire. Автор PipeWire вроде как прислушивается к тому, что ему говорят парни, пишущие звуковой софт, поэтому есть некоторая надежда сделать ситуацию не такой печальной.

  • У Пола накопился ряд претензий к JACK, который он сам же когда-то и создал. Особенно не нравится JACK2, который написан совсем другими людьми. В какой-то момент Пол сложил с себя все полномочия мейнтейнера и с тех пор пребывает в счастливом неведении, что там вообще происходит. Поддержку JACK из программы никто не выпилит, но пользователям Ardour он советует пользоваться бэкендом ALSA, при использовании которого всё просто работает.

  • OMF и AAF – хреновые форматы для обмена проектами, добавлением их поддержки в команде никто не хочет заниматься. Есть некий интерес к OpenTimelineIO, но надо смотреть более предметно.

  • VCV Rack – офигенный проект, Пол признается, что вынужден себя режимить каждый раз, когда запускает этот синтезатор, иначе может играться просто часами (в перерыве между выходами двух частей подкаста я ему с подачи @ist76 показал SOLAR 50, и Пол за полвечера накидал похожий софтовый аналог в Рэке). Сейчас модулей для Rack вдвое больше, чем LV2-плагинов, хотя проекту всего три года, а LV2 – уже больше десятка лет. Сказалась идея на старте прибить гвоздями модули к ровно одному, но очень мощному синтезатору, и убрать у разработчика сложный выбор, на каком тулките писать GUI. Перенести этот опыт на LV2 априори невозможно, но в последнее время выручают фреймворки, с которыми можно генерировать плагины в любом формате (т.е. под любой популярный API). Это заметно улучшает ситуацию со скоростью разработки и доступностью плагинов.

  • Mixbus как единственный успешный коммерческий отпрыск Ardour выжил потому, что разработчики а) на старте не имели проблем с GPL (Solid State Logic сломались уже на этом), б) приняли подход команды к разработке GUI (на этом погорели Waves Audio со своим Tracks Live), в) оказались готовыми интегрироваться в процесс разработки Ardour (тут Waves тоже нишмагли – в какой-то момент кодовые базы безвозвратно разошлись).

★★★★★

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

а нахрена вообще тулкит для управления параметрами плагина

Потому что аккуратное графическое представление набора элементов позволяет, во-первых, представить управление в перевариваемом человеком виде. Во-вторых, как говорится, встречают по одёжке. Одно из главных НЕудовольствий - это именно крутить generic-интерфейс плагина. Нормальный WYSIWYG интерфейс решает эти проблемы на корню.

почему не сделать, как в linuxsampler: зацепился к сокету и хоть обуправляйся

А графики вы как по сокету рисовать будете?

Управление по сокету можно свести к банальной отправке OSC-сообщений. Это-то сделать несложно. Я, как раз, планирую в standalone-версиях что-то вроде того реализовать, но после апгрейда до 1.2.0.

так вообще ни один компилятор или ни один компилятор Си?

Ну почему? Компилятор ассемблера вполне себе выразителен. Более высокоуровневые компиляторы не смогут…

а где тогда альтернативные, более современные и продвинутые языки?

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

  • Векторизация высокоуровневыми языками сложных алгоритмов?
  • Нет, сынок, это фантастика!
sadko4u ()
Ответ на: комментарий от sadko4u

А графики вы как по сокету рисовать будете?

я пожалуй открою тайну, но далеко не всем плагинам нужны графики (тем более, околореалтаймовые)

Управление по сокету можно свести к банальной отправке OSC-сообщений.

например

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

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

anonymous ()

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

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

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

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

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

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

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

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

Вот именно для этого(звукозапись, например) и есть rt-патчи для ядра. Даже при загруженном ядре приоритет будет там где надо.(в нашем случае у *audio).

Справедливости ради, замечу, что у меня XRUN’ы при буфере 64 сэмпла тоже есть. Сыпать начинает когда проматываю страницы в браузере или переключаюсь между столами со звуковым набором и браузером. Может в моём ноуте видео и usb на одной PCI-шине… ХЗ.

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

в винде (и наверное в маке) всё работает без рт-патчей для ядра. проблема в том, что поттеринга переклинило и всё поехало в юзерспейс, а когда ему сказали, что это проблема, то он завёл шарманку про not a bug, а редхет включил ЕЕЕ: https://ru.m.wikipedia.org/wiki/Embrace,_Extend,_and_Extinguish

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

какбы опенсорс, да, можно прислать патч, но его не примут, а если примут, то потом откатят, потому что «We do not condone or support XXX in the course of action they have chosen, and will not carry YYY patches upstream. -The Management»

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

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

наверное не очень приятно такое читать на сайте про линукс, но такова объективная реальность.

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

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

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

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

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

Чо? Не вижу трудности поставить rt-ядро. Нам ведь результат нужен?

S_Paul ★★★★ ()