LINUX.ORG.RU

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

 ,


2

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 тоже нишмагли – в какой-то момент кодовые базы безвозвратно разошлись).

★★★★★

Последнее исправление: AP (всего исправлений: 3)

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

А чего там Жириновский задвигал? Каждому мужику по бабе, хлеб заводам, компьютеры учёным, и всё такое :)

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

морду для lv2 на кутях не генерирует, мол, кути больше не котируются, всё везде поломано, пиши морду сам

А зачем тебе стандартная морда на Qt, если есть такая же по функциональности стандартная морда от DAW, которая гарантированно работает и ее не надо генерировать?

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

Мне ещё и dbmeter нужен. В нескольких экземплярах, и только для эксперимента. И никак побырику ее накидать

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

Тут никак. Я при отладке просто по очереди интересующие сигналы на выход вывожу и смотрю через scope или meter что там.

Отладка плагинов это боль.

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

А там это есть? Я не большой специалист по джеку, но что если параллельно работающие приложения с разной задержкой будут?

А что ты подразумеваешь под задержкой?

Размер буфера у всех jack приложений одинаковый будет - связанные с ним задержки соответственно тоже.

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

curufinwe ★★★★★
()
Последнее исправление: curufinwe (всего исправлений: 2)
Ответ на: комментарий от anonymous

так ведь Си (даже без классов) - тоже самое и есть

Из полезного у C++ - возможность распихать функции и структуры по неймспейсам, виртуальные функции, иногда темплейты бывают полезными (в очень умеренном количестве). Автоматический вызов деструкторов для локальных объектов может местами облегчить работу с памятью. Остальное всё от лукавого.

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

В jack есть возможность рапортовать о latency, создаваемом плагином.

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

p.s. вот, посмотри в C:/Documents and Settings/All Users/Application Data/gtk-3.0/settings.ini C:/Documents and Settings/username/Local Settings/Application Data/gtk-3.0/settings.ini

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

Через Проводник не получается никак - во-первых, ясно что проводник показывает не настоящие имена папок, а локализованные «Пользователи», «Общие» и так далее. Во-вторых Application Data скрыта.

Я всегда заходил туда, вводя в адресной строке путь. Но теперь никак не получается - пишет что никакой Application Data не существует.

А нет - она есть, но нет прав на вход туда! Так может поэтому у гимпа крыша и съезжает?

Вот же блин система готова для десктопа.

curufinwe ★★★★★
()
Последнее исправление: curufinwe (всего исправлений: 1)
Ответ на: комментарий от ChekPuk

потому что воспользоваться существующими наработками гуёв FalkTX и sadko4u - непонятно, что они там навертели, а в гуях я ничего не понимаю, а стандартного решения нет ибо свобода у нас от стандартов.

В LSP Plugins 1.2.0 гуи будут оформлены отдельным репозиторием. Вы сможете взять и и использовать на своё усмотрение.

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

ОК, а «на другие не переключается» значит что именно? Не раскрывается список с языками? Или раскрывается и даёт выбрать, но переключения после перезапуска программы не происходит?

Да, раскрывается, все языки есть, но выбор ничего не меняет. Переустановил еще раз внимательно - локали точно установлены.

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

И я с ними согласен - нахрен все эти векторы, авэиксы, спекулятивные чего-тотам… Я хочу просто, скриптовенько написать логику работы моего приложения. Мне плевать на низкоуровневую составляющую, она должна автоматически всё оптимизировать.

https://cellperformance.beyond3d.com/articles/2008/03/three-big-lies.html

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

как с этим у LV2 или VST хостов, это как-то учитывается?

Разумеется учитывается. Называется «компенсация задержки». LADSPA, LV2 и VST имеют механизмы передачи хосту дополнительной задержки сигнала, которую они создают.

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

Так а как в нее войти - прав то нету. Запустить проводник от админа не понимаю как - у него такой опции через правую клавишу нет.

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

Во-вторых Application Data скрыта.

Это у всех вендузятников такое с неспособностью освоить свою ОС? %APPDATA% в адресной строке и ты уже там. В любой венде, начиная с XP, если не раньше.

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

Нет, погодите, ‘can report latency’ - это немного другое. У JACK-приложений есть возможность по каждому аудиопорту сказать, какую задержку он в сигнал вносит. Вопрос в том, учитывает ли jack эту задержку, когда коммутрирует аудиопотоки, или нет.

sadko4u ★★
()
Последнее исправление: sadko4u (всего исправлений: 1)
Ответ на: комментарий от Stanson

Это у всех вендузятников такое с неспособностью освоить свою ОС?

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

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

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

%APPDATA% в адресной строке и ты уже там. В любой венде, начиная с XP, если не раньше.

Чисто для протокола - это ответ неверный.

Так что ты совсем не виндузятник, с чем и поздравляю. Серьезно.

P. S. Беру свои слова назад и извиняюсь - твой метод работает. Так что ты все-таки спец по винде.

curufinwe ★★★★★
()
Последнее исправление: curufinwe (всего исправлений: 1)
Ответ на: комментарий от AP

Короче - ни в какую. Только английский работает.

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

или конфиги gtk-2
посмотри там что-то похожее по смыслу

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

Да прекратите вы уже Gnome и GTK использовать, сколько можно!

Уже не первый раз GTK/Gnome уличаются в банальном несоблюдении стандартов. Вернее, они плодят свои стандарты вместо того, чтобы поддерживать имеющиеся.

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

Я то не использую, я же не разработчик GIMP :)

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

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

По моему это должно обрабатываться секвенсорами для компенсации каждой дорожки, не? Плагин сообщает хосту, хост джеку, джек мастеру, мастер решает какую дорожку с какой задержкой/опережением начать проигрывать при нажатии «плей». Ну, это было в моём представлении о профессиональном софте, как это в Ардорах и Кутракторах с Элмэмээсами я не знаю.

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

Позвольте докажу обратное.

lsp-plugins> make clean && make -j8 test
lsp-plugins> .test/lsp-plugins-test ptest dsp.filters.static

Получаем:

--------------------------------------------------------------------------------
LSP version: 1.1.22
--------------------------------------------------------------------------------
CPU information:
  Architecture:   x86_64
  CPU string:     AMD Ryzen 7 2700 Eight-Core Processor
  CPU model:      vendor=AMD, family=0x17, model=0x8
  Features:       FPU CMOV MMX FXSAVE SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 SSE4A XSAVE FMA3 AVX AVX2
--------------------------------------------------------------------------------

Statistics of performance test 'dsp.filters.static':
┌Case──────────────────────────┬Time[s]┬───Iter┬Samp[s]┬────Est┬Perf[i/s]┬Cost[us/i]┬Rel[%]┐
│native::biquad_process_x1 x8  │  10.00│ 799000│  10.00│ 798799│ 79879.97│   12.5188│107.32│
│sse::biquad_process_x1 x8     │  10.00│ 808000│  10.00│ 807635│ 80763.58│   12.3818│108.51│
│avx::biquad_process_x1 x8     │  10.01│1071000│  10.00│1070371│107037.18│    9.3425│143.81│
│avx::biquad_process_x1_fma3 x8│  10.01│ 745000│  10.00│ 744304│ 74430.44│   13.4354│100.00│
├──────────────────────────────┼───────┼───────┼───────┼───────┼─────────┼──────────┼──────┤
│native::biquad_process_x2 x4  │  10.00│1488000│  10.00│1487514│148751.43│    6.7226│116.00│
│sse::biquad_process_x2 x4     │  10.00│1283000│  10.00│1282392│128239.27│    7.7979│100.00│
│avx::biquad_process_x2 x4     │  10.00│1404000│  10.00│1403319│140331.95│    7.1260│109.43│
│avx::biquad_process_x2_fma3 x4│  10.00│1381000│  10.00│1380840│138084.04│    7.2420│107.68│
├──────────────────────────────┼───────┼───────┼───────┼───────┼─────────┼──────────┼──────┤
│native::biquad_process_x4 x2  │  10.00│1870000│  10.00│1869154│186915.46│    5.3500│100.00│
│sse::biquad_process_x4 x2     │  10.00│3083000│  10.00│3082373│308237.37│    3.2443│164.91│
│avx::biquad_process_x4 x2     │  10.00│3417000│  10.00│3416206│341620.64│    2.9272│182.77│
│avx::biquad_process_x4_fma3 x2│  10.00│3631000│  10.00│3630336│363033.67│    2.7546│194.22│
├──────────────────────────────┼───────┼───────┼───────┼───────┼─────────┼──────────┼──────┤
│native::biquad_process_x8 x1  │  10.00│1837000│  10.00│1836170│183617.02│    5.4461│100.00│
│sse::biquad_process_x8 x1     │  10.00│3049000│  10.00│3048621│304862.14│    3.2802│166.03│
│sse3::x64_biquad_process_x8 x1│  10.00│5649000│  10.00│5648231│564823.18│    1.7705│307.61│
│avx::x64_biquad_process_x8 x1 │  10.00│3774000│  10.00│3773788│377378.87│    2.6499│205.52│
│avx::biquad_process_x8_fma3 x1│  10.00│4269000│  10.00│4268859│426885.96│    2.3425│232.49│
└──────────────────────────────┴───────┴───────┴───────┴───────┴─────────┴──────────┴──────┘
Performance test 'dsp.filters.static' has succeeded, execution time: 170.15 s

Коротко о тесте: тестируется банк из 8 последовательных биквадратных фильтров на буфере в 512 семплов. Что такое биквадратный фильтр: https://en.wikipedia.org/wiki/Digital_biquad_filter

  • native:: - реализация на Си++

  • sse::, sse3::, avx:: - использование функций с ручной оптимизацией под соответствующий набор команд процессора (грубо говоря - векторизованный код на ассемблере).

  • x1 - алгоритм принимает на вход 1 биквадратный фильтр и обрабатывает буфер из 512 семплов, и так делается, пока все 8 фильтров в пачке не будут применены.

  • x8 - алгоритм принимает на вход сразу 8 биквадратных фильтров и обрабатывает с их помощью буфер из 512 семплов.

Иными слвами, x1 - 8 фильтров поштучно, x8 - 8 фильтров одной пачкой, x2 и x4 - промежуточные варианты. Заметим ещё раз, что фильтры объединены последовательно, а не каждый обрабатывает свой буфер из 512 семплов.

Каждый тест запускается на буфере в течение 10 секунд и считается количество отработавших циклов обработки с шагом 1000 (то есть, время замеряется на каждом 1000ом шаге итерации, чтобы минимизировать задержки на дополнительных библиотечных/системных вызовах).

В итоге, нормированное количество выполненных итераций в секунду (третья справа графа) и время выполнения одной итерации (предпоследняя графа).

А теперь сравниваем:

  • native::biquad_process_x1 - 12.5188 микросекунд на итерацию
  • native::bilinear_transform_x8 - 5.4461 микросекунд на итерацию

То есть, просто переписав алгоритм на использование 8 последовательных фильтров вместо одного и сделав его потенциально векторизуемым, мы уже его ускорили в 2.3 раза.

Теперь переходим к «тяжёлой артиллерии» и оптимизируем алгоритм руками, просто написав соответствующий ассемблерный код:

  • sse::biquad_process_x8 - 3.2802 мксек (буст в 3.8 раза)
  • sse3::x64_biquad_process_x8 - 1.7705 мксек (буст в 7 раз)
  • avx::x64_biquad_process_x8 2.6499 мксек (буст в 4.7 раз)
  • avx::biquad_process_x8_fma3 - 2.3425 мксек (буст в 5.3 раза)

Очевидно, что ручные оптимизации с использованием машинных кодов значительно лучше справляются, нежели компилятор. Почему AVX отработал хуже - особенности работы арифметики Ryzen поколения Zen+, там ещё AVX неполноценный, поэтому sse3 с использованием 16 xmm-регистров оказывается быстрее (видимо, лучше параллелится на уровне микрокоманд).

Этот тест подтверждает следующее утверждение:

Though there are a lot of performance penalties for this kind of design, the most significant one is that it doesn't scale. At all. One hundred rockets costs one hundred times as much as one rocket. And it's extremely likely it costs even more than that! Even to a non-programmer, that shouldn't make any sense. Economy of scale. If you have more of something, it should get cheaper, not more expensive. And the way to do that is to design the data properly and group things by similar transformations.

То есть, мы одним тестом показали, что 8 фильтров стоят в разы дешевле, чем если бы мы применяли их поштучно. Именно такие оптимизации и позволяют вашему JACK’у не иксрунить. А если разработчики не будут думать о таких оптимизациях и впредь - ваш JACK и будет впредь иксрунить.

sadko4u ★★
()
Последнее исправление: sadko4u (всего исправлений: 3)
Ответ на: комментарий от sadko4u

Не, я не спорю, что ты монстр, в хорошем смысле слова. Но на спектруме было как? Сел и пишешь. Никаких библиотек и прочей дряни, только бейсик (и ассемблер для монстром типа тебя). Сидишь, пишешь. Единственный стандарт - интерпретатор бейсика и архитектура компа, простейшая. Никаких тебе векторов. Бажестьвенно!

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

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

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

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

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

Пафос не пафос, а я уже три четыре пострадал как минимум:

  1. GTK не работает под JUCE-based хостами. Просто банально не получает X11 Events.
  2. Работа с INCR протоколом не реализована нормально. Передача больших буферов обмена между приложениями проблематично.
  3. Drag&Drop тоже работает через жопу, если стороннее X11-приложение встроилось в GTK-окно через ReparentWindow.
  4. Стандарт XDG? Да нафиг он нужен! https://www.reddit.com/r/linux4noobs/comments/g40e3a/unwanted_lsp_plugins_showing_up/
sadko4u ★★
()
Ответ на: комментарий от AP
Ответ на: комментарий от sadko4u

Кстати, я вчера наново ставил твои плагины, обратил внимание, что вывалило их кучей в меню «Мультимедиа» и ещё в «Прочее» насыпало. Вроде раньше они в своё субменю прятались? Это в Манжаре, в КДЕ, видимо, последний релиз. Проверить не могу, через три дня только домой поеду.

ChekPuk ★★★
()
Последнее исправление: ChekPuk (всего исправлений: 1)

BTW хотел бы обратить ваше внимание на досуге. Некие товарищи говорят, что сделали обработку звука на GPU и хотят продавать это самым крупным плагин-мэйкерам (например - Abbey Road). https://rmmedia.ru/threads/139205/

Моё краткое изложение:

Нечто имеет типовые DSP блоки и прогоняет обработку через видеокарту (только NVIDIA). К этому «нечто» цепляемся из DAW через VST. Нужна отдельная видяха так как утилизируются все CUDA ядра.

Второй, весьма интересный момент. GUI для плагинов сделаны на CEF (https://www.google.com/search?client=firefox-b-d&q=CEF+chromium), то есть рисуются ручечки-ползунки на вебе и дёргаем-гоняем данные по сети.

Обсуждение весьма странное благодаря самим авторам, я тоже попытался поговорить, но всё сводится к «у нас такие приборы, но мы вам об них не расскажем». Бизнес-модель я пока опущу, там какой-то детский лепет.

Интересно?:)

PS. Помимо готовых базовых DSP блоков вроде как можно пилить самим свои обработки. И либо будут давать SDK за деньги, либо давайте им свой код - они сами перепилят(!).

kott ★★★★★
()
Последнее исправление: kott (всего исправлений: 1)
Ответ на: комментарий от kott

GUI для плагинов сделаны на CEF

Блин, куда не сунься, везде веб-сервер запихивают и требуют браузером цепляться. Помешательство прям какое-то.

Обсуждение весьма странное благодаря самим авторам, я тоже попытался поговорить, но всё сводится к «у нас такие приборы, но мы вам об них не расскажем».

Идея обработки DSP на видяхах интенесная, но:

  1. Насколько помню, сейчас GPU особой точностью вычислений не блещет, из-за чего все, кто рендерит видео, предпочитают делать это на CPU. Если не прав - поправьте.

  2. Сколько времени уходит на пересыл данных из CPU в видеокарту и получение ответа? Будет ли это укладываться в концепцию realtime обработки данных?

  3. GPU хорош там, где данные хорошо параллелятся. Например, обработка FFT или FEM-симуляция какая-то. Как компрессоры и прочая динамическая обработка будет работать на GPU, где каждый семпл взаимосвязан с предыдущим - загадка.

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

Судя по ответам это типичные денисы поповы. Вангую что у них ничего нет.

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

Paul Davis пишет такую daw, которая ломает гуи плагинам так, а rncbc пишет daw, который ломает гуи сяк.

С больной головы на здоровую :)))

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

Отвечу тут. На счёт сохранения Jack-сессий - я нашёл для себя aj-snapshot. Сохраняет в файл все соединения.

Всем привет.

S_Paul ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.