Reaper 5.93 Linux Native Experimental (1 онлайн
- Автор темы Netmansky
- Дата начала
Да никак. RT-ядро - это же специальный набор костылей, которые ты должен использовать в своем софте. Чтобы твой софт получил некие условные RT-возможности (условные потому, что любой правильно спроектированный bare metal софт по времени реакции покроет все эти костыли как бык овцу).
Так вот теперь задайтесь вопросом - кто там что в alsa сделал для использования этих RT пирогов? И что сделал Джастин для поддержки этого дела в Рипере? И что во всяких VST-плагинах (и в костылях для их запуска) сделано?
Как по мне, то для звука всё, что быстрее 1 сэмпла - это Риал Тайм.
Дима, у нас сейчас минимальный пакет 8 сэмплов?
Ну вот - как только частота процессора возрастёт в 8 раз - получим RT.
Дима, у нас сейчас минимальный пакет 8 сэмплов?
Ну вот - как только частота процессора возрастёт в 8 раз - получим RT.
Совершенно верно. Все дискуссии на тему создания музыки в линукс среде нужно начинать с этого и этим же сразу заканчивать. Потому что там говорить больше не о чем...
Не буду спорить с автором кооперативной многозадачки на Siemens E27/EL27)
Что касается остальных тезисов, Ваши знания о Linux сильно устарели. Лет на двадцать. Это понятно по упоминаниям Reaper под Linux, Alsa round-trip latency и т.п. Другие люди спрашивают про барабанную сессию, видно что даже старый-добрый гидроген никогда не видели. Это скучно, ессно никто не сидит в рипере при наличии двух десятков своих daw работающих через pulse. Понимаете, это с Linux контейнеризация пришла на Win, а не наоборот. У меня (да и у всех, сегодня) есть конкретные примеры сколько контейнеров можно запустить на ядре Linux и сколько на Win, на одном и том же железе. Разница кратная. И с ней ничего не сделать, потому что не живут контейнеры на золотом ядре Win. Не живут от слова вообще "никак", т.к. нельзя коматоз этот жизнью назвать. А вы рассказываете состояние дел на Linux образца 2002 года, как будто ядро за это время никак не менялось, никакого поттеринга не было и экосистема никак не росла. Понятно, что вы не живёте в Linux давно (с того же 2002 года), мнение сложили и готовы поделиться, вполне компетентно. Это уважаемо, но не более. Сегодня, если мне уж так нужна винда я могу запустить виртуалку, и выводить звук с этой виртуалки - AGA? На Linux на своём домашнем ПК я могу запустить около 80 виртуальных машин, контейнеров и эмуляторов, и смикшировать звук из них в одной из DAW, хотя бы в Ardour. Это пофиг какая DAW работает микшером. На win будет что? Правильно, труба. Поэтому в Linux можно иметь сумму всех существующих экосистем, а в Win - только win-экосистему. Разница в этом.
@aGGreSSor, да никому эти виртуалки в музыкальном продакшне не нужны. Когда на линухе раундтрип в пару-тройку десятков семплов покажете, тогда и говорить будем. Если что - на винде легко.
А со скольки контейнеров можно звук на вывод микшировать - дело нафиг никому не нужное. Покажите рекорды по входу-обработке-выходу. Пока оно там десятками миллисекунд измеряется - нафиг не надо.
А со скольки контейнеров можно звук на вывод микшировать - дело нафиг никому не нужное. Покажите рекорды по входу-обработке-выходу. Пока оно там десятками миллисекунд измеряется - нафиг не надо.
У меня пока очень малый список из того, что не работает (в основном, ревера, причём как ни странно, больше, видимо, из-за интерфейсов). Разница в производительности с win на уровне статистической погрешности.
Написал уже 2 симфонических альбома + кучу разных оркестровок и живых записей.
ЧЯДН?
Я искренне не понимаю, зачем нужна latency в 8spl, если даже при 512 никаких затруднений что-то сыграть\спеть (в том числе и с софт-мониторингом) не вызывает. И уж тем более, на нормальном железе можно работать в 128 и в ус не дуть.
Мне икренне интересно поковыряться в том, как устроен ALSA и можно ли его как-то твикать\оптимизировать под интерфейс, но в целом со стороны DAW и Digital Audio у меня ещё ни разу претензий за последние 3 года активной работы на Ubuntu Studio не возникало.
Когда начинаешь тот же компьютер использовать для игрушек и графики — начинаются терзания, какое ядро поставить или загрузить, но в целом — один раз закрыл вопрос с настройкой, и потом не поднимал.
Я, типа, понимаю, что быстрее, правильнее и безопаснее будет написать расширение к тому же Reaper на rust. На котором, в принципе, хватает библиотек и экосистемы почти на все аудио-дела. Но пишу на Python — потому что удобнее, на пару порядков быстрее и работает достаточно нормально, для того, чтобы пользоваться. И не надо кросс-компилировать 
В принципе, на Win старенький ноутбук пишет немного стабильнее (но тоже не безгрешно), да. Но удобство и возможности jack с лихвой компенсируют затраты на лишний десяток сэмплов задержки. На мой вкус
P.S. проблема Digital Audio на Linux в том, что сидят дядьки из большого рынка и думают, что аудио на Linux занимаются откровенно больные люди, которые нихрена не понимают, не умеют и вообще не люди. А главное, наверное, думают они, они не заплатят.
И, возможно, в последнем пункте они хоть немного правы. Хоть я стабильно закупаюсь в Steam. Но надо понимать, что Linux — это в первую голову GNU и философия open-source: если меня не устраивает софт — я его допиливаю. И это не какие-то красивые слова — а гарантия того, что твоя работа не накроется медным тазом ночью с субботы на воскресенье. Я регулярно лезу в исходники и делаю себе хорошо И нам, в принципе, не важно, заплатили мы перед этим за программу, или заплатили после, или заплатили тем, что выкатили патч, или вообще не заплатили. Главное — что за софтом стоит сообщество.
А вот по поводу профессионализма — мне вот прямо сейчас присылают партитуры из последней версии Sibelius. И после Lilypond (это аналог LaTex для нот) и профессиональных взрослых изданий смотреть и играть по такой партитуре грустно.
P.P.S. Понятно, что на Sibelius можно сделать супер-классно. И вообще профессиональному типографу инструмент не так важен. Но всё-таки, из коробки он заметно проигрывает.
В принципе, на Win старенький ноутбук пишет немного стабильнее (но тоже не безгрешно), да. Но удобство и возможности jack с лихвой компенсируют затраты на лишний десяток сэмплов задержки. На мой вкус
P.S. проблема Digital Audio на Linux в том, что сидят дядьки из большого рынка и думают, что аудио на Linux занимаются откровенно больные люди, которые нихрена не понимают, не умеют и вообще не люди. А главное, наверное, думают они, они не заплатят.
И, возможно, в последнем пункте они хоть немного правы. Хоть я стабильно закупаюсь в Steam. Но надо понимать, что Linux — это в первую голову GNU и философия open-source: если меня не устраивает софт — я его допиливаю. И это не какие-то красивые слова — а гарантия того, что твоя работа не накроется медным тазом ночью с субботы на воскресенье. Я регулярно лезу в исходники и делаю себе хорошо
И нам, в принципе, не важно, заплатили мы перед этим за программу, или заплатили после, или заплатили тем, что выкатили патч, или вообще не заплатили. Главное — что за софтом стоит сообщество.А вот по поводу профессионализма — мне вот прямо сейчас присылают партитуры из последней версии Sibelius. И после Lilypond (это аналог LaTex для нот) и профессиональных взрослых изданий смотреть и играть по такой партитуре грустно.
P.P.S. Понятно, что на Sibelius можно сделать супер-классно. И вообще профессиональному типографу инструмент не так важен. Но всё-таки, из коробки он заметно проигрывает.
Последнее редактирование:
Да почему сразу "неправильно". Правильно.
То, что производительность на больших буферах не зависит от ОС - так и должно быть, железо-то одно и то же. А на больших буферах накладные расходы составляют очень малую часть.
Все проблемы начинаются тогда, когда надо шагнуть в область меньших латенси.
Есть еще отдельные тонкости, связанные, например, с взаимным соотношением приоритетов потоков, например, в Рипере. Плохо там дело, например, на Макоси (хотя и есть условно правильный способ, но Джастин им почему-то не пользуется, в результате на MacOS нужные потоки не получают приоритет 96, а остаются в диапазоне приоритетов порядка 40). Возможно, что уже переделано, я давно не проверял, но мы имели с Джастином по этому поводу беседу.
Но вот в Линухе аналогичная MacOS история банально невозможна. Нет там бескостыльного способа изменить приоритет потока так, чтобы он стал максимальным.
Мне, как человеку, пользующемуся аудио-интерфейсами собственной разработки и драйверами для них собственного написания видимо сложно понять, какие-такие особые удобности и возможность предоставляет jack. Уж пардон.
кстати, это да — мне тоже с приоритетами потоков договориться не получилось(((
Ну по сравнению с собственным написанием, конечно, всё остальное по удобству проигрывает))
Но я как страшный сон забыл проблемы с одновременной работой двух муз программ, роутингом миди и аудио между приложениями и т.п. Вот только сегодня в Zoom слал микс из 6 микрофонов, хотя он воспринимает только одну главную стереопару с интерфейса — просто потому что с Jack приложению не нужно иметь свою логику для поиска источников.
А это тоже накладные расходы на разработку и использование: вот недавно писал простенький скрипт для того, чтобы использовать графический планшет как midi-контроллер. В jack было достаточно открыть порт rtmidi и слать в него дату. Для Windows же надо было бы писать отдельное меню для выбора порта (если повезёт), или устанавливать виртуальный миди-кабель (если не повезёт).
Опять-таки. Понадобилось сегодня посреди трансляции запустить аудио с компьютера. Не знаю, есть ли этот функционал в Zoom, но на поиск решения под win я бы потратил энное количество времени. А в jack — просто воткнул выход pulseaudio на вход pulseaudio)
Ну у меня для этой цели в драйверах
а) мультиклиентность в смысле нескольких ASIO-приложений, работающих одновременно
б) специальные дополнительные шины-лупбэки.
Если одному приложению надо отправить в другое, то просто отправляешь на один из этих bus'ов, а в другом приложении ставишь этот bus как вход. WDM у меня тоже умеет настраиваться входами и выходами в том числе и на эти шины.
Вот буквально на днях роутил из своей DAW звук далеко в мир. В Cubase на мастер-шине поставил посыл на этот самый bus, в WDM настроил вход как этот самый bus, запустил параллельно ffmpeg, входом на WDM (а к сожалению, он ASIO не умеет), а выходом - отправил поток на свой выделенный сервер где-то в Канаде, там второй ffmpeg в качестве ретранслятора, и клиенты по миру разбросанные, которые слушают звук во вменяемом качестве при помощи ffplay -i url_сервера.
А чтобы беседы вести, где какую партию сделать тише-громче - банальная конференция в телеграме рядом ))))
И с этой самой маршрутизацией я вполне справился без alsa. Вот конечно без ffmpeg'а фиг бы справился с разумными временными затратами. И, кстати, несмотря на то, что VPS у меня, понятное дело, под линухами, поднимать мне там alsa было нафиг не надо.
Но с другой стороны такую же штуку я бы вполне провернул на каком-нибудь RME с его собственными лупбэками. Нафига мне та alsa - я хз.
Ну а между компами в локалке мой драйвер тоже умеет носить данные, вообще без лишних дополнительных костылей. Ну т.к. и интерфейсы-то подключаются Ethernet'ом, то сделать из компа псевдо-интерфейс тоже было не сильно проблематично.
@Rst7, Это всё круто, да! Вообще, конечно, перед вашими разработками я снимаю шляпу! Но... Когда я спрашивал у Александра, каковы шансы и затраты на то, чтобы всю эту красоту завести хотя б на 8 XLR-входов — он развёл руками, и сказал, что рынку этого не надо и делать штучный товар не получится.
Поэтому у меня под роялем пашет Midas XR-18, и я на нём давно уже использую не только 8 дырок...
Поэтому у меня под роялем пашет Midas XR-18, и я на нём давно уже использую не только 8 дырок...
У нас есть готовый макет. 8 входов, 8 выходов. Несмотря на то, что рынку этого действительно нафиг не надо, рынку вон за 100 баксов девайс на стол подавай. Но тем не менее люди, которым надо много каналов - они есть, и макет мы сделали. Если не считать корпуса, который банален - то это, в принципе, суть опытный образец.
Но! Ситуация сейчас такая, что производить не из чего. 26 апреля прошлого года я заказал на Маузере десяток микроконтроллеров, которые мы заложили в девайсы по этому проекту. Сначала обещали отгрузить в конце мая. Потом пошли письма - "ожидаемая дата отгрузки - июнь", потом август, потом октябрь, потом январь (уже нынешнего), в январе пришо - 10 мая, а в феврале - "мы будем консультироваться". С кем и о чем они будут консультироваться - я хз, но процессоров нет и, походу, не будет.
И каждый день новости. Заходишь на Диджикей, заказать какую-нибудь комплектуху, которую заказывал месяц назад, и она была, а там - In stock 0, lead time 52 weeks. Т.е. ждать год. Я не понимаю, как в таких условиях вообще начинать серийное производство, потому проект нами поставлен на паузу до нормализации ситуации на рынке полупроводников.
Думал, что в ситуации тотального ухода виндоус, тема Линукс для музыканта получит, как минимум, продолжение.
ох, надо будет найди пару дней — написать статью про VSTi продакшн в Linux+Reaper.
Хотя мне сейчас стало интересно покопать Ardour, как уж совсем открытую DAW, которая оказалась стабильнее. Но для этого надо найти свободный месяц)
Хотя мне сейчас стало интересно покопать Ardour, как уж совсем открытую DAW, которая оказалась стабильнее. Но для этого надо найти свободный месяц)
@vinnipooh1988, ну reaper с vst тоже только через bridge. Сейчас в менйстрим выходит yabridge. Я не могу сказать, что можно пользоваться чем-то одним. 80% кнотактовских библиотек у меня через VSTi и LinVST пашут. А менее прожорливые — через VSTi3 и yabridge. Остальные плагины сейчас через yabridge, т.к. он более просто интегрируется в arch и manjaro в частности.
github.com
вот такой есть гид по настройке. Но я в итоге отказался от pipewire и на рабочей машине, и на полевом ноутбуке, потому что pipewire по-умолчанию подключает сразу все интерфейсы, какие есть, включая виртуальный (зачем?). И это сильно бьёт по производительности. Старый-добрый cadence + jack2 гораздо надёжнее.
GitHub - ElizabethHarmon/ManjaroProAudio at 69d91ec8574f3ec827cea48c9ac805db7ba32b75
A complete guide to setting up Manjaro for professional audio. - GitHub - ElizabethHarmon/ManjaroProAudio at 69d91ec8574f3ec827cea48c9ac805db7ba32b75
github.com
А что тут можно подробнее? В macos есть способ (штатный) дать потоку приоритет выше всех. В том числе выше системных. Там прямо специальный костыль (штатный) поверх типичного юниксового шедуллера прибит в ядре для этого.
В линухах такой возможности нет.
По макос - запросто, https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/scheduler/scheduler.html
А по линухам трудно дать ссылку на то, чего нет в природе ))))
где тут про костыль поверх шедулера? ядро открыто, можете ткнуть пальцем: https://github.com/apple/darwin-xnu
нет чего, выставления приоритета у процесса или потока? https://man7.org/linux/man-pages/man7/sched.7.html
и рипер это делает:
99 - это не самый максимально возможный приоритет, если что.
Если Вы поищете BASEPRI_RTQUEUES вот в этом файле - https://fergofrog.com/code/cbowser/xnu/osfmk/kern/sched_prim.c.html
(более удобный просмотрщик, чем в гитхабе
), то увидите большую кучу всяких изменений поведения при установке такого приоритета.Вообще в макос есть приоритеты пользовательские, 0-63. потом идут приоритеты ядра, а потом, на уровне 97 снова доступный из юзер-спейса приоритет. Если приоритеты пользовательские и ядерные обрабатываются единообразно, то вот rt-приоритет имеет кучу особенностей.
а какой? на картинке линукс, если что
поискал, в основном увидел отключение переброски rt процессов между ядрами, в линуксе это тоже делается.Если Вы поищете BASEPRI_RTQUEUES вот в этом файле - https://fergofrog.com/code/cbowser/xnu/osfmk/kern/sched_prim.c.html
(более удобный просмотрщик, чем в гитхабе
но я понял, что вы имеете в виду, дескать, в макоси есть rt приоритет, а в линуксе - нет
Не совсем так. В Макоси можно поставить приоритет потоку выше всех (в том числе, и выше потоков ядра), а в Линухе - нельзя. Я про юзерсспейс, если что.
И выше 99 бывают. Но только в ядре.
И совсем по другому там вытеснение начинает работать (оно продолжает работать, потому что между потоками с приоритетом 97 есть конкуренция, но по другому), да плюс еще таймауты на максимальное время выполнения этих потоков, там много чего, чтобы нельзя было уронить систему.
Гигасэмплер работал только на карте Turtle Beach Pinnacle на Win98, он был в неё интегрирован и поэтому эти знания скорее всего нам ничего не дадут. Работал же долгое время протулс только на MAC и с звуковой картой Digidesign, тоже была интеграция на уровне драйверов. А вообще Гигасэмлер для своего времени была штука революционная и звучание казалось на уровне железных синтезаторов. года три пользовался, но под миллениум драйверов не`нашёл (интернета в те года ещё не было), пришлось распрощаться с Pinnacle и Nemesys Gigasampler.