Я хочу всегда все индикаторы видеть
Это потрясающе. Как вы это делаете. Никогда ничего подобного у меня не получалось. Понятно, что асио гуард в том или ином виде, без него то вообще была бы жопа
Mac на ARM Apple Silicon
- Автор темы A-Record23
- Дата начала
-
- Теги
- arm
@Anton Vorozhtsov, у вас же кубейс? Это вдвойне потрясающе, потому что в кубе у меня даже с буфером 128 ничего не работает, только 256+
@N0-body, кубейз, да. Старенький Saffire Pro 40 для этих всех дел, и точно так же все стабильно работало раньше на мак мини 2012. Может у вас обработка дропауты дает? Попадаются иногда плагины, дающие кратковременные спайки цпу, со слейтом/па такого нет, ими и пользуюсь для мониторинга. А может с охлаждением у вас проблемы, термопасту давно меняли? У меня пару-тройку недель назад возникла такая необходимость, началась жара и все стало усираться при малейшей нагрузке, капелька MX-4 - и все стало как прежде.
Асио гард на полную включен, конечно.
Асио гард на полную включен, конечно.
Дело в том, что при общей задержке, например, порядка 4.5мс (это какие-нибудь 64 семпла размер буфера) произвольный VST-хост, работающий через ASIO, сможет нормально обрабатывать больше плагинов, чем при работе через CoreAudio. Это значит, что в среднем Вам надо подняться в MacOS на ступеньку выше по размеру буфера.
Пардон, а какое отношение имеет asio guard к каналам, на которых включен режим мониторинга?
Есть такое. Особенно когда несколько раз введешь неправильный пароль от учетки (ну бывает, человек забыл что должна быть большая буква) то внезапно макОС уходит в глубокую *нальную оборону с просьбой все дальнейшие мероприятия по вводу пароля проводить на сайте Эппл Айди и не чаще раза в сутки кажись)
народ, создайте в разделе про win топик о домохозяйках, блондинках и преимуществах win и там флудите. засрали весь топик уже, хватит
Вероятно, инструменты. Аккуратно подбирая обработки, можно как-то работать с маленьким буфером. Но одна любая пианинка (контакт, галион, кейскейп, что угодно), и всё, до свидания.
На винде те же самые проекты с теми же плагинами работают с меньшими буферами, это увы факт
Я вст пока не трогаю - разрабатываю плагины RackExtension кроссплатформенные. И результаты на вин10 и маке в одном буфере, весьма одинаковы при обработке.
для меня это хороший показатель как можно жить на маке или винде если ты в коробке Reason.
и в этом месте Вани аргументы просто не работают про ступеньки буфера. Есть расхождения без криминала. Совсем не на порядок..
Конечно же займусь этим вопросом через несколько месяцев когда буду оптимизацией заниматься вст и ау. Там это меня затронет в большей степени, там и ощущу, я ж не спорю про данные форматы, мой спик пока касается иных форматов плагинов, где такого четкого криминала по работе с буфером я не вижу. Это мой опыт и никого не призываю ни к чему. И знаю что кораужио и Асио на вст к примеру точно разнятся по буферу в работе.
для меня это хороший показатель как можно жить на маке или винде если ты в коробке Reason.
и в этом месте Вани аргументы просто не работают про ступеньки буфера. Есть расхождения без криминала. Совсем не на порядок..
Конечно же займусь этим вопросом через несколько месяцев когда буду оптимизацией заниматься вст и ау. Там это меня затронет в большей степени, там и ощущу, я ж не спорю про данные форматы, мой спик пока касается иных форматов плагинов, где такого четкого криминала по работе с буфером я не вижу. Это мой опыт и никого не призываю ни к чему. И знаю что кораужио и Асио на вст к примеру точно разнятся по буферу в работе.
Последнее редактирование:
Уж не знаю, в формате плагинов дело, или еще в чем - но Ризон в до-встшную эпоху был, наверное, самым стабильным хостом. За все время пользования не помню не единой проблемы, падения или вылета. Жаль, что с добавлением функционала они не торопятся, так бы, наверное, на нем и сидел
И есть ещё одна скрытая от пользователей особенность Core Audio - если вы при записи сигнала не верно настроили буфер в DAW и услышали на мониторинге дропаут - вы его и ЗАПИШИТЕ!
А на Винде с АСИО большинство нормальных карт будут писать чистейший сигнал даже при слышимых на выходе дропаутах.
@Rst7 писал об этом, но по ходу пользователей Мак ОСи и это устраивает, как и завышенные в два раза задержки.
Последнее редактирование:
@Aleksandr Oleynik, ну что значит устраивает. С одной стороны задержка. С другой стороны куча бытовых нюансов. Выбираем наименьшее из зол.
Ну или как вы это видите? Почему я, понимая разницу в задержках, продолжаю плакать, колоться и пользоваться макос? Меня же там ничто не держит. Если количество страданий от макос превысит количество страданий от виндовс, я просто поставлю виндовс на свои маки. Пока ещё это возможно)
Ну или как вы это видите? Почему я, понимая разницу в задержках, продолжаю плакать, колоться и пользоваться макос? Меня же там ничто не держит. Если количество страданий от макос превысит количество страданий от виндовс, я просто поставлю виндовс на свои маки. Пока ещё это возможно)
@Aleksandr Oleynik, про пену и прочее это ж не к вам) зерокул так возбудился эпитетами в теме в сторону мака что явно понесло человека. Да и в целом был вектор задан отдельными посетителями)) это я не про вас
@N0-body, Не....
@baloo, БЕЗУСЛОВНО прав - у многих нет ни какой необходимости в малой задержке, ну или они научились работать с той, которая есть.
Я ведь прекрасно понимаю и написал об этом в другой ветке - ПОЧЕМУ 90% Музыкантов в США работают на Мак-ах.
Но это не мешает мне и Диме искать вариант дать возможность Мак Юзерам работать с меньшей, чем у Коре аудио задержкой.
Кстати, мы нашу идею обсудили с Джастином - хозяином и разработчиком Reaper-а. Он не задумываясь сказал, что сделает тут-же в Рипере поддержку такого решения.
@baloo, БЕЗУСЛОВНО прав - у многих нет ни какой необходимости в малой задержке, ну или они научились работать с той, которая есть.
Я ведь прекрасно понимаю и написал об этом в другой ветке - ПОЧЕМУ 90% Музыкантов в США работают на Мак-ах.
Но это не мешает мне и Диме искать вариант дать возможность Мак Юзерам работать с меньшей, чем у Коре аудио задержкой.
Кстати, мы нашу идею обсудили с Джастином - хозяином и разработчиком Reaper-а. Он не задумываясь сказал, что сделает тут-же в Рипере поддержку такого решения.
Зерокул по жизни вспыльчив и не дипломат аж ни разу... Ну вот такой он и другим не будет.
НО!!!!! Он не безразличный человек и ПРОФИ с большой буквы - а это, на мой личный взгляд, перевешивает все его отрицательные черты...
Я не общаюсь и не работаю только с БЕЗРАЗЛИЧНЫМИ людьми, со всеми прочими, если нужно, всегда найду общий язык.
Так что - не вижу причин не обсуждать дальше Mac на ARM Apple Silicon.
Последнее редактирование:
Дело не в формате плагинов. Дело исключительно в способе передачи данных из CoreAudio/ASIO в DAW и обратно и в обработке ситуации, когда время обработки буфера в DAW превысило время между двумя приходами новых данных.
В ASIO (правильно написанном, но сейчас уже все они правильно написаны) единоразовый такой overrun будет полностью скомпенсирован хвостовым буфером, например, в самой аудиокарте.
В CoreAudio все хуже, там если не успел до прихода следующей порции данных, то безусловный дропаут. И по входу, кстати, тоже.
Теперь почему это важно. Дело в том, что время, затрачиваемое на обработку в плагинах не есть константа. Есть другие процессы, прерывания, непопадания в кэши и прочие побочные накладные расходы, которые непредсказуемы. В среднем единоразовые выбросы могут достигать порядка 3*среднее_время_обработки. Выглядит это так - тысяча буферов обрабатывается за время T, а тысячепервый - за какие-нибудь 3*T.
Если, скажем, T примерно равно 50% от времени между двумя приходами данных (т.е. buffer_size/f_sample), то на этот тысячепервый раз в CoreAudio будет дропаут с последующей потерей следующего буфера на входе, а в ASIO будет просто неполное опустошение хвостового буфера в карте (неполное - если он выбран с достаточным запасом), а затем постепенное его наполнение до обычного уровня, т.к. в среднем производительность в два раза выше, нежели полностью критическая (когда T=buffer_size/f_sample).
Именно в этом и кроется смысл выражения "ASIO более производителен, чем CoreAudio". Потому что для CoreAudio надо обеспечить, чтобы 3*T было строго меньше buffer_size/f_sample, а для ASIO - 3*T<(buffer_size+tail_size)/f_sample. Множитель 3 - это, скажем так, опытным путем полученная цифра. В каждом конкретном случае она может меняться, но ее порядок именно такой. Иногда криворукие писатели непосредственно при написании плагина могут провалить явки и этот коэффициент может стать и 10, и 20, и сколько влезет, но это уже вопросы к конкретным рукожопам, и тут не рассматриваются.
Есть еще нюанс, что CoreAudio точно так же ведет себя и на этапе получения данных из драйвера и помещения их в буфер для последующей обработки. И там тоже приходится вставлять небольшой дополнительный буфер.
Принципы работы с буфером у ВСТ и РЕ различаются.
Понятно что некоторые разработчики сливают размер внутреннего буфера в большую строну для выигрыша производительности, это происходит по факту местами. И с крупными игроками.
У РЕ внутренний буфер для всех один как стандарт. И потому компенсация хоста работает хорошо. У вст кто в лес кто по дрова нет четких установок. В этом как минимум разница.
Понятно что некоторые разработчики сливают размер внутреннего буфера в большую строну для выигрыша производительности, это происходит по факту местами. И с крупными игроками.
У РЕ внутренний буфер для всех один как стандарт. И потому компенсация хоста работает хорошо. У вст кто в лес кто по дрова нет четких установок. В этом как минимум разница.
Именно по этой причине в Рипере (и на Винде и на Маке) буфер плагина всегда кратен буферу хоста, в не зависимости что там плагин хосту сообщил!
Всё это так смешно и грустно, если вспомнить, что поделки типа linuxcnc ещё в древние времена пентиумов могли молоть циферки вообще поштучно, без буфера. И это работало совершенно надёжно даже для продакшна с огромной ценой даунтпйма. Если бы кому-то из производителей бытовых ОС было хоть немного не пофиг, со звуком это могло бы работать так же
А как же имоджи? Их ведь нужно генерит в контексте...
Современные бытовые ОСи обросли кучей большинству не нужных системных процессов и драйверов. И для них для всех нужен системный буфер. И приоритеты им разработчик ОСи ставит не в пользу мизерной группы пользователей, которым нужен РеалТайм Аудио.
Выход - писать свою собственную ОСь - но это совершенно тупиковый путь, от которого уже ВСЕ отказались.
Но у плагина изначально определён буфер. Стыковка буферов плагинов разного калибра происходит меняя правила игры, без затрат производительности?
Идеальной ОС для пользователя быть не может, борьба приоритетов.
Вот та же ELK OS на базе линукса внушает минимальные задержки для производителей плагинов, желающих перевести из в железку.. Там конечно Солянка в сборке.. но если она даёт заявленные результаты..?
Софт + железо - и ведь есть хорошие результаты по факту задержек у них
Вот та же ELK OS на базе линукса внушает минимальные задержки для производителей плагинов, желающих перевести из в железку.. Там конечно Солянка в сборке.. но если она даёт заявленные результаты..?
Софт + железо - и ведь есть хорошие результаты по факту задержек у них
Безусловно без. Определение компенсационного буфера в DAW не происходит онлайн - один раз опросил, плагин ответил, выставил - всё.
Буфер самого плагина в общем к производительности не имеет ни какого отношения.
Плагины с не нулевой задержкой это как правило плагины требующие лукахеда.
Время обработки сигнала плагином всегда НА МНОГО меньше буфера хоста, и это время, в плагинах требующих лукахеда, не прямо связанно с собственным буфером плагина. Если у плагина есть не нулевой собственный буфер, то как правило он нужен только для того, чтобы получить нужное ему колл-во сэмплов на вход ДО всякой обработки.
@Aleksandr Oleynik, да то и обидно, что это всё (насколько я понимаю) решаемо совершенно без ущерба для эмоджи, плавных анимаций и сранного автоапдейта. У современных процессоров достаточный запас мощности, чтобы оплатить накладные расходы на реалтайм планирование.
Но тут возникают политические вопросы. Как быть уверенным, что криворукие сторонние разработчики в реалтайм процессы, предназначенные только для аудио, не напихают всякую срань, которая всё заблокирует, а виноват в глазах пользователя окажется производитель ОС.
Но тут возникают политические вопросы. Как быть уверенным, что криворукие сторонние разработчики в реалтайм процессы, предназначенные только для аудио, не напихают всякую срань, которая всё заблокирует, а виноват в глазах пользователя окажется производитель ОС.
Я не знаю, что такое "РЕ", но это совершенно непринципиально. Смысл проблем совершенно в другом, я их выше описал.
В смысле? Что значит "без буфера"? Можно, конечно, и по одному семплу носить, но это будет столько накладных расходов, что мрак.
Да и какое отношение имеет эта поделка, которая ногодрыгом в порту принтера пытается шаговые моторчики крутить, к аудио?
Что опрос присходит разово на старте это понятно. Но внутренние буфера есть свои повсюду - в том же Izotope к примеру.. и прочих. И они разнятся.
и его приведение к нормальной работе в среде Reason в 64 сэмпла по началу жрало ресурсы именно плагинами из за неразберихи с буферами.. как и прочими плагинами имеющими свой буфер.. из за этого были проблемы по началу, производительность плагинов была низкой. Для вст был пересмотрен подход по оптимизации производительности именно в ракурсе выставления буфера, в итоге производительность ВСТ в Ризоне в целом встала под 64 дефолтно как должно быть, и проблемы ушли, создав равные условия работы вст прочим дау.
я в теме ВСТ пока частично нуб хотя имею готовые сборки и разбираться в этом огороде мне по хорошему только предстоит.
потому у и сужу со своей колокольни из тепличных условий, имея достаточный опыт по РЕ на обеих платформах.
в том и суть ВСТ что это больше не набор правил, а только рекомендаций, и поэтому стабильность ВСТ не столь высока в зоопарке платформ ОС и дау, в сравнении с чёткими правилами сдк ризона.
Но это все внутренние нюансы, пользователю совсем не интересные, и может быть воспринято в штыки, и это будет зря) не о том речь.
разговор про буфер кораудио и асио я вёл исключительно из собственного опыта разработки, прекрасно видя результаты ВСТ разнений по буферам.
и его приведение к нормальной работе в среде Reason в 64 сэмпла по началу жрало ресурсы именно плагинами из за неразберихи с буферами.. как и прочими плагинами имеющими свой буфер.. из за этого были проблемы по началу, производительность плагинов была низкой. Для вст был пересмотрен подход по оптимизации производительности именно в ракурсе выставления буфера, в итоге производительность ВСТ в Ризоне в целом встала под 64 дефолтно как должно быть, и проблемы ушли, создав равные условия работы вст прочим дау.
я в теме ВСТ пока частично нуб хотя имею готовые сборки и разбираться в этом огороде мне по хорошему только предстоит.
потому у и сужу со своей колокольни из тепличных условий, имея достаточный опыт по РЕ на обеих платформах.
в том и суть ВСТ что это больше не набор правил, а только рекомендаций, и поэтому стабильность ВСТ не столь высока в зоопарке платформ ОС и дау, в сравнении с чёткими правилами сдк ризона.
Но это все внутренние нюансы, пользователю совсем не интересные, и может быть воспринято в штыки, и это будет зря) не о том речь.
разговор про буфер кораудио и асио я вёл исключительно из собственного опыта разработки, прекрасно видя результаты ВСТ разнений по буферам.
Я Вам щас объясню. Лет 15 назад мы делали привода для станков с ЧПУ. Там прямо с последовательной шины микроконтроллер выхватывал нужные для оси G-коды, интерполировал их и крутил мотор. Причем, мотор был нифига не шаговый, а асинхронный. Контроллер привода был сделан на ATMega88. Это 8мибитный процессор, 8к флеша программ, 1к ОЗУ. Тактовая частота 20МГц. Ну где-то он там с CPU Load порядка 50% работал.
Вот, собственно, и вся "dsp с жестким реальным временем". Можете экстраполировать 8 бит 20МГц на древний пентиум и домножить на количество осей
Вот, собственно, и вся "dsp с жестким реальным временем". Можете экстраполировать 8 бит 20МГц на древний пентиум и домножить на количество осей