Comments 18
По сути AsioForAll не дают задержку, каковые дадут нормальные Asio дрова и железки. Я до сих пор использую SBLive!, по меньшей мере на вин7 с kxdrivers оно работает. А ведь это одна из самых важных штук, если вы работаете именно с музыкой и реальными midi контроллерами.
Супернизкая задержка нужна только при мониторинге голоса. Даже чтобы поиграть на VST синтезаторе, требования уже меньше.
Вы правы, супернизкая задержка нужна в основном для мониторинга голоса и для игры на гитаре (играть очень сложно, когда ты сначала сылшишь настоящие струны, и через 30 миллисекунд ещё раз, обработанные). Для написания музыки приходится отказываться от этого, чтобы плагины не лагали, ведь нужно же какое-то время для обработки
Низкая задержка 5-10 миллисекунд при традиционном музицировании группой нужна на всех стадиях музпроизводства, за исключением сведения и мастеринга, где часто буфер вынужденно ставят на 512 мсек из-за злоупотребления "улучшайзерами". О задержке говорят прежде всего гитаристы с медиатором (резкая атака), потом вокалисты, и позже всех MIDI-клавишники (они слышат задержку только по выходу, условно половину задержки).
Например, на стадии записи/сочинения - персональный ушной мониторинг со "своим" миксом для каждого музыканта, настроенный им со смартфона по WiFi (штатный функционал DAW Reaper) - та штука, от которой, попробовав раз, решительно невозможно отказаться. Музыкантов словно меняют, они перестают конкурировать и "уходят в выразительность и звукоизвлечение". Я молчу про кратное снижение нагрузки на слух музыкантов, звукорежа, продюсера, зрителей, домашних и животных.
ASIO4All - это на грани стабильности и расстройства психики, хотя некоторым везет (c психикой и железом). Но занятие музыкой - слишком священное хобби, чтобы продолжать жалеть на него 3-10 тыс. руб. на нормальную быструю ASIO-карту. Для Linux примерно 50% таких устройств работают удивительно хорошо (узнавайте заранее на профильных форумах) и задержкой если не ниже, то "такая же", как и в Windows. Добавление в эту схему Wine все равно оcтавит за бортом около 30% важных и привычных VST/VSTi, поэтому жертвы неизбежны. А QUEMU с 5-кратным ростом DPC практически неюзабелен.
Ну я как раз MIDI - клавишник и задержка в 15 мс уже ощущается. Я за это дело очень люто боролся еще в 2006 году, подключая даже осциллограф двухканальный. Потому что играешь - а на выходе смещение. Знаете, вот есть такой прикол против орущих людей - все что они исторгают ртом, записывается в некий буфер и им же с задержкой в полсекунды озвучивается через рупор, колонку. Мигом желание орать и ругаться пропадает, человек перестает слышать себя и от этого дезориентируется. С музыкой это тоже проблема - клавиши ты нажал, а звук получил уже когда нажимаешь совсем другие клавиши. Очень, я вам скажу, демотивирует. ВСТ синты и так в то время проц грузили по полной, поэтому задержка очень критична. На асио задержка достигается от 5 до 10 мс, тут уже нормально. А в остальном вы все правильно говорите.
Асио"для всех" тоже имеет применение но не для живой игры. Его главный прикол - на любой условной реалтек встройке звучке получить минимум задержки. Для музыки руками эта задержка неприемлема конечно, а вот для работы в секвенсоре - нормально. Собсна и появились эти дрова не от хорошей жизни для тех музыкантов, у кого на "железо" не было денег или желания. В том же фрутилупсе работая чисто в секвенсоре эти задержки не играют особой роли (это справедливо для любой DAW), но если использовать стоковые дрова которые ставит винда или производитель матплаты - даже там будет очень больно. Только это асио - не настоящий прямой доступ к звуковухе, можно провести сравнение с видеокартами - на нвидиа есть пакет CUDA, который сильно расширяет возможности по вычислениям. Ну вот настоящий асио - это примерно то же самое, только большая часть встроена в хардваре, а типичные дрова с этим не умеют работать. Только и всего.
А я вот сижу и думаю, как мне это хозяйство хоть как-то изолировать на Винде.
Средствами администрирования винды, в простонародье - калиткой в поле, потому что много чего устанавливается с правами администратора, а значит может вживляться во всё, до чего дотянется, и воровать все файлы со всех дисков, которые только сможет увидеть. Поэтому я и экранировал Wine - чтобы переиграть эту проприетарную жесть. Она всё ещё может воровать файлы и передавать их в разные корпорации, вот только она ничего не видит. Не просто не может изменить или прочитать, а вообще не знает о существовании чего-то за пределами префикса. А если ещё через Flatseal заблокировать интернет для Lutris - то всё это малварьё не сможет передать то, до чего может дотянуться, а именно - файлы проектов и наработок. Только так с проприетарщиной. Главное, чтобы бэкдоров не было
То есть ты фактически не доказал, не смог обнаружить или найти следы деятельности вредоносов или кряков - но боишься этого страшно, готов ради этого испытывать боль в qemu?
Вести дебаты "вы все под присмотром корпораций и случайных хакеров" против "вы все шизики с шапочкой из фольги" можно бесконечно, приводя минусы как проприетарного ПО (невозможно проверить), так и опен-сурса (мало кто проверяет), так что эта тема с подобными дебатами равносильна спорам по интересам и ценностям каждого человека, что вообще не имеет смысла. Бывают люди с психологической потребностью в безопасности, поэтому сам факт наличия возможности тырить их файлы - для них критичен. Бывают творческие люди, которые не хотят, чтобы их идеи подвергались опасностям быть украденными или стёртыми. И да - ради безопасности они готовы на многое: изучать программирование, скрипты, программы, фундаментальные принципы работы компьютеров, учиться мыслить на столь глубоком уровне, чтобы выстраивать защиту и продумывать заранее все возможные каналы утечек информации. Для них простое чувство защиты - значит больше, чем возможность поиграть в игрушечки или посмотреть сериалы по подписке через официальное приложение онлайн-кинотеатра, которое пускает корни аж до ядра системы (вдруг ты захочешь это приложение взломать, у какой нехороший). И таких людей больше, чем может показаться на первый взгляд.
На qemu надо было сделать проброс звуковухи как PCI девайса. Ну и ещё вроде для винды есть драйвера какие-то для видеокарт, но это не точно
Да, можно перебрасывать звуковую карту, но желательно чтобы хост мог мониторить её звук, иначе пропадает часть возможностей. Про видеокарты - в теории должен существовать метод, когда гостевая система думает, что к ней подключена настоящая видеокарта, отправляет на неё API запросы типа DirectX или OpenGL, а виртуальная машина тут же переводит это на настоящую видеократу и обратно. Говорят, что такой метод, в теории, должен быть идеальным, кушать очень мало ресурсов (имеются в виду расходы на перенаправления), позволять играть в игры в миллион FPS. Но из такого я находил только Linux->Linux, а Linux->Windows не находил. Если кто найдёт - подскажите, интересно попробовать.
Справедливости ради - Wine опять прикалывается, и решил, что теперь ничего не должно работать. Ни Nectar3, ни GuitarRig - не работают от слова совсем. Вообще без причин. Придётся пробовать, экспериментировать, тратить ещё десятки часов. Так что на способ с QEMU тоже стоит присматриваться, правда для него нужна вторая GPU или хотя бы интегрированная в процессор, а такие не везде есть...
UPD. АХАХАХАХАХА. GuitarRig и Nectar3 заработали. Я на момент подумал - вдруг им всё-таки нужен winedevices. И реально - теперь всё работает прекрасно. Придётся переписывать эту инструкцию. Но все эти диски в dosdevices надо убирать, иначе воткнул флешку - и GuitarRig уже не работает, например. А вдруг будет работать... Вот до чего ваш Линукс доводит
Как то все слишком мучительно) я использую PortProton для установки всего виндового - и игр и софта, и плагинов. Затем вам нужно конвертировать ваши dll в .so что бы софт линуха воспринимал их нативно. Для этого можно использовать yabridge или LinVST. Первая по опыту ковертирует значительно большее кол-во плагинов. Ну это все в том случае если студия нативно работает в линукс - типатого же Ardour или Reaper.
UPD. Всё ещё пытаюсь найти нормальные и вменяемые способы для запуска 32 битных плагинов. Перерыл весь интернет по третьему разу, нашёл в bugzilla похожее замечание: https://bugs.winehq.org/show_bug.cgi?id=44827. Видимо, разработчики Wine не особо торопятся. В общем, тут есть способ запустить 32 битный VST без зависания, но он странный, и всё равно связан с External Window: добавляете Fruit Wrapper, нажимаете шестерёнку, потом VST Wrapper Settings (плагин и шестерёнка, второй пункт), и заменяете на нужный VST. Так он откроется, но без графики. Там же выбираете External Window. Увы, пока не нахожу нормального способа обойтись без External Window.
UPD 2. Во время переезда на другой диск и переустановки системы, я обнаружил странное поведение GuitarRig - он крашил Wine, причины были неизвестны. Я сменил Wine на "staging-tgk", GuitarRig заработал, но этот Wine почему-то очень сильно лагает (особенно если открыть контекстное меню). Поэтому я вернул Wine обратно, на "ge-8-26-x86_64", и включил Esync и Fsync. И оно работает. При чём работают вообще все плагины, и без багов с лагающим интерфейсом (RetroColor) или вылетами (Izotope Ozone) как раньше. Для включения Esync нужно добавить строку "имя-пользователя hard nofile 524288" в файл "/etc/security/limits.conf" (если у вас НЕ SystemD), и перезайти в иксы.
Так же в процессе вспомнил, что некоторые активаторы генерируют неправильные ComputerID, но у многих плагинов достаточно посмотреть логи, чтобы узнать правильный и вставить в активаторы (только никому не говорите).
Так же важно: если вы развернёте в настройках Lutris дополнительные параметры, то НЕ СТАВЬТЕ GPU НА СВОЮ ВИДЕОКАРТУ, ставьте "Автоматически". Иначе начинаются приколы, когда окнам становится доступна только половина экрана.
Ещё из опыта - если отключаете интернет для Lutris, то в нём нельзя создавать новые префиксы, вылетает ошибка Wine. Временно включите ему интернет, если хотите поставить что-то.
Пока что, последней и единственной проблемой остаётся работа VST 32bit в External окнах. Но жить можно. Хотя хотелось бы, конечно, чтобы они работали в Internal режиме.
Хотел описать ещё одну проблему, но я её забыл. Берегите своё здоровье и соблюдайте режим сна, чтобы не забывать ничего. Ну а на счёт проблем - не стесняйтесь писать сюда, в комментарии, если у вас есть какие-то проблемы. Вместе разберёмся!
UPD. Снова на связи. После глобального обновления одной из важнейших библиотек в Линуксе (мне не посчастливилось сначала не обновить все пакеты, пришлось поиграться с Live образом для ремонта), FL начала странно себя вести - при запуске на долю секунды видно фрукт, а потом вылет. В логах пишут про ошибку Иксов, но как и положено Wine - это не настоящая причина. Узнал, что лаунчеры в Lutris можно качать и через сам Lutris - надо в списке "раннеры" нажать на коробочки рядом с Wine. Скачал версию "lutris-fshack-7.2". Сначала оно зависло на этапе настроек, но при втором запуске заработало. Магия
UPD. Проблема с постоянными крашами при запуске никуда не делась. Нашёл интересную штуку в Lutris - установку с заранее настроенной средой, где нужно лишь указать нужный вам установщик (должен быть видимым для Lutris!). В Lutris нажимаете плюсик в левом-верхнем углу, первый пункт, вводите "fl-studio", выбираете какой-нибудь из пунктов (я выбрал последний по дате, список есть тут https://lutris.net/games/fl-studio) и не забудьте указать путь на папку внутри Flatpak/Lutris, типа "/home/user/.var/app/net.lutris.Lutris/games/flsuper", а не "/home/user/Games" или типа того, ведь мы экранировали Lutris! Вроде как способ рабочий, пока что плагины ставятся хорошо, багов нет. Есть конечно подозрения, что прошлая попытка вылетала из-за обновления системы, но тут не знаю, что сказать
UPD. Зачем я каждый раз пишу UPD? После того я как я научился разгонять герцовку монитора, обнаружил, что отключение скринсейвера в Wine при нестандартных разрешениях экрана или нестандартной герцовке приводит к некому софт-локу когда X11 отключает монитор. Рекомендую снимать галочку в "Параметры системы" -> "Отключить скринсейвер". Дополнил эту инструкцию
LINUX + FL Studio + платные VST (32+64)