Core Audio vs. ASIO (1 онлайн

[Aleksandr Oleynik]

Я отключил!
В Моих проектах и при малых задержках он снижает эффективность ASIO на 10-15%, а именно нагрузка на ASIO, а не загрузка процессора, является иголочным ушком производительности, увы.....
Я не могу загрузить 6 процов выше 60%, чтоб при этом ASIO не начало спотыкаться. В общем-то по этой причине я и напряжение на CPU, для большей стабильности разогнанного проца, поднимаю прилично, так как при 60% загрузки процессора не получаю экстремальных температур и через два-три часа непрерывной работы.

 

[mexap]

Elle, у меня i5

 

[krosslove]

какие нагрузки на асио? Вот я читаю и не вижу у себя такого. 3 компа на одном ай 3 на двух других ай 5. Везде треск начинается ТОЛЬКО при 100 процентной загрузке процессора. Загрузка асио - миф. Иначе не скажешь

 

[Dmytro_ua]

Загрузка асио - миф.

ну да...

 

[Aleksandr Oleynik]

Один из способов чуствовать себя счастливым - просто не подозревать ничего о своих несчастьях.

 

[basЫl]

в конкретном виде проекта проблему нехватки ASIO можно решить только повышением частоты CPU, то есть гнать, ставить на воду, азот и т.п.. (это не касаясь оптимизации алго под конкретные камни). Так как (в очередной 2753 раз поясню) загрузка ASIO - это загруженность процессора для выполнения (с учетом мультиядерности чаще всего самой длинной) последовательной цепочки инсертов за указанное время асиобуфера

 

[Alf_Zetas]

какой смысл гнать проц, если он и так недозагружен (60%) работой? - после разгона загрузка ЦПУ уменьшится до 40%, но асио как было 100% загружено так и останется

 

[Elle]

асио как было 100% загружено так и останется

ребят, на мой взгляд, утверждать, что "ASIO загружено" не совсем корректно, т.к. ASIO-метров никаких вроде нет, да и ASIO - это программный интерфейс взаимодействия с картой, он не может быть как-то загружен.
Надо просто отдавать себе отчёт в том, что есть несколько факторов, влияющих на воспроизведение звука без глитчей. Это и загруженность процессора, и размер буфера, и скорость жёсткого диска при воспроизведении многодорожечных файлов, и пропускная способность шины, памяти. И т д и т п. Это целая система, которую в зависимости от целей можно как-то оптимизировать, выявлять и избавляться от различных bottleneck'ов. Тем не менее, некоторые закономерности всё-таки есть. Например, гнать процессор работает достаточно эффективно практически всегда, т.к. даже если беда с DPC - в единицу времени процессор может успеть обработать больше чужих DPC-запросов и вероятность не завалить аудиобуфер повышается. Это впрочем не гарантия решения проблем во всех случаях.

 

[basЫl]

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

минутка ликбеза:
основная печаль, которую мало кто замечает - сайдчейны.
пример: рулим бочку, стоит на ней 4 обработки, посылаем посыл (хы..) например на компрессор другого трека (пусть базз), после компрессора стоит еще 3 обработки. смотрим в микшер - "блин, по 4 обработки на трек стоит, что ж тормозит-то" - нихера, пока не обработается цепочка инсертов на бочке, цепочка на басе ЖДЕТ!! (а время отведенное на обработку всего асиобуфера идет!), и только после цепочки бочки начинает обрабатываться цепочка инсертов на басе, поэтому суммарно за время буфера процу надо обработать 8 инсертов подряд за отведенное время. По тому же принципу печалят посылы на тяжелые реверы, и еще на мастере висит тяжелый лимитер (мы же не будем пользоваться плохими ))). поэтому, ИНДИКАТОР ASIO показывает по большей части загрузку проца для просчета самой длинной цепочки взаимозависимых эффектов (не будет считать, пока не посчитаются предыдущие).

тупой пример на картинках:

вот 2 эффекта - вывод независимый. Индикатор ASIO показывает максимум из всех загрузок. (очень грубо говоря - пока свободных ядер больше чем параллельных потоков).


вот 2 эффекта, но реверб не будет считаться пока не посчитается инсерт на 1 треке, а время буфера ASIO такое же. ОП! загрузки складываются! и понеслось.


также добавляют баттхерта посторонние процессы, они-то и дают непрогнозируемые пики ASIO, ибо времени посчитать остаток буфера все меньше, а тут еще и дефраг полез, антивирь, почта проверяется, +Дрова у железок не идеальные. (почему у пирамикса так все интересно - они не знаю на каком уровне исключили ядро камня ИЗ ВСЕХ СИСТЕМНЫХ процессов - для стабильности, поэтому в их распоряжении вся ничем не отвлекаемая мощь ядра - как тру DSP)

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

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



ну или подождите еще немного...

 

[Aleksandr Oleynik]

какой смысл гнать проц, если он и так недозагружен (60%) работой? - после разгона загрузка ЦПУ уменьшится до 40%, но асио как было 100% загружено так и останется

Оказалось, что смысл самый что ни на есть прямой.
При всех прочих равных условиях, мой проект для Лайва с 64 spl буфером начинает выдавать глитчи при показателях RT CPU в Рипере начиная с 65% устойчиво, полностью их нет до 50%.
Повышая частоту проца (разгоном), я прямо пропорционально снижаю % загрузки RT CPU.
Вот и всё ASIO.

 

[basЫl]

если адово глитчит на малых загрузках имеет смысл посмотреть на посторонние процессы. Вообще можно сделать спец. тачку с "дауншифт"-системой и поотключать ВСЕ (прямо реально все!) процессы и службы, при которых хост (и система) еще запускается.
я как-то лет 8 назад проводил подобный эксперимент, но выяснить все зависимости служб и процессов терпения не хватило, так как отключая неизвестный процесс можно уронить систему, и все заново.

В связи с темой возникает вопрос: есть ли смысл в "красивостях" интерфейса, всякие тени, полупрозрачности, эффекты, переходы (OpenGl в интерфейсе (омг..)) - если потом возникает попоболь с асио и вопросы типа "кто сожрал мои CPU-попугаи?"

 

[Aleksandr Oleynik]

если адово глитчит на малых загрузках имеет смысл посмотреть на посторонние процессы. Вообще можно сделать спец. тачку с "дауншифт"-системой и поотключать ВСЕ (прямо реально все!) процессы и службы, при которых хост (и система) еще запускается.

Что значит адово? Если на концерте, во время игры, да ещё в какой-то тихой части композиции, начинает подшепётывать и поскрежётывать - считаю это не допустимым.
Это всё уже сделано!
В другой теме обсуждали..... (или в этой, на много раньше, я уже запутался)

В связи с темой возникает вопрос: есть ли смысл в "красивостях" интерфейса, всякие тени, полупрозрачности, эффекты, переходы (OpenGl в интерфейсе (омг..)) - если потом возникает попоболь с асио и вопросы типа "кто сожрал мои CPU-попугаи?"

Это всё МИЗЕР!!!!!!!!!! Ваще ни как не влияет в современных условиях мощностей процессоров!
Самый жручий процесс в моей системе (на PDC) - DirectX Graphics Kernel, но он НИКАК не зависит от нагрузки на граф. карту со стороны интерфейса винды....., или я не знаю что ещё отключать.
Но он = 0,180990 ms, все прочие существенно ниже - и ЭТО ПРИ работающем Лайв проекте в котором включены все arm-ы по входам и мониторинг (что добовляет нагрузки на RT CPU СУЩЕСТВЕННО, кстати!).

 

[Alf_Zetas]

т.к. ASIO-метров никаких вроде нет

официально в ДАВ єто индикаторы "Average Audio Processing load" & "Maximum (RT) Audio processing load" - а по народному "загрузка ASIO"

Это целая система,

в просторечии всю эту систему для краткости и называют ASIO, а не только сам программный интерфейс

Например, гнать процессор работает достаточно эффективно практически всегда,

гнать только проц, да еще множителем, малоэфективно - он всего лишь часть системы Гнать нужно всю систему - гнать шину, память гнать, звуковуху гнать (заменой ЮСБ на РСІе) etc

 

[Aleksandr Oleynik]

гнать только проц, да еще множителем, малоэфективно - он всего лишь часть системы Гнать нужно всю систему - гнать шину, память гнать, звуковуху гнать (заменой ЮСБ на РСІе) etc

Я проверил - при всех прочих равных, разгон Только проца (множителем) даёт вполне адекватный результат, во всяком случае, когда остольное в уупоре (либо реально уже лучше ничего не сделать, либо знаний не хватает)...
При разгоне i7-4960X с его 3,6 до 4,3 - я могу буфер, используемый в проекте, опустить c 128 на 64 spl - а это, при такой вот кратности - получается, что я всю свою Сиситему улучшил в Двое.

 

[Aleksandr Oleynik]

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

ЭТО ВСЁ ТАК И ЕСТЬ!
Но есть ещё одна печаль, во всяком случае в Reaper-е Именно так! - существенный прирост загрузки ASIO (RT CPU) даёт включение канала записи с мониторингом.
Безусловно от сложности проекта, кол-ва плагинов на канале, роутинга и сайдчейна результат разный может быть, но у меня хороший проект для подобных тестов - в нём около 80 дорожек, есть двух уровневые посылы, есть треки с цепочкми до 6 плагинов, есть модули с сайлчейном. В проекте участвуют 18 инструментов (всё вместе).
Так вот при выключенном Record Armed имею RT CPU = 3,8% (при плее всех 18-и дорожек в проекте = 5,2%)
А стоит на 18-и каналах его включить = 30%

Это данные при разогнанном проце до 4,3 GHz,

при отсутствии разгона (проц 3,6 GHz) -
при выключенном Record Armed имею RT CPU = 5,2% (при плее всех 18-и дорожек в проекте = 5,8%)
При включенном Record Armed на 18-и каналах = 35%

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

 

[Alf_Zetas]

при такой вот кратности - получается, что я всю свою Сиситему улучшил в Двое.

это просто из-за большой дискретности шага изменения буфера так кажется - а реально при разгоне на 20% ты уменьшаешь пресловутую "загрузку АСИО" на 5% - но именно тех, что тебе не хватало

 

[Aleksandr Oleynik]

это просто из-за большой дискретности шага изменения буфера так кажется - а реально при разгоне на 20% ты уменьшаешь пресловутую "загрузку АСИО" на 5% - но именно тех, что тебе не хватало

ДА! Согласен! (правда в моём случае, разгон с 3,6 на 4,3 это около 20% действительно, а вот 35% и 30% RT CPU, это не 5, а как минимум 15$% прироста!).
Но, как ты правильно заметил, именно их мне и не хватало, ну и других методов я всё равно пока не нашёл (кроме, конечно, оптимизации самой обработки в проекте, его роутинга и прочего, что в моих руках и что конечно-же сделано (с помощью Zerocool-а)).

 

[Dmitry Stepin]

Так вот при выключенном Record Armed имею RT CPU = 3,8% (при плее всех 18-и дорожек в проекте = 5,2%)
А стоит на 18-и каналах его включить = 30%

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

 

[windoze]

Макбук про очень дружит с Лайвом.
Win PC всегда летает, при минимальных затратах. Проверено большим опытом работы.) НО! Нужно быть продвинутым юзером - это раз.
Связка DAW и драйвера карты - РЕШАЕТ. Разный софт имеет разную архитектуру, опыт разработчиков на вин и на маке. Некоторые программы так и не становятся мультиплатформенными по сим причинам.
Лайв эффективностью никогда не славился - заточен не для этих целей. В этом основная проблема. Также с ним надо понимать его подход к лэйтенси в мониторинге (он отличается от остальных).
Счастливая жизнь с одним только Лайвом на PC возможна..но стоит присмотреться к альтернативам с самого начала. Чтобы потом не огорчаться. Лайв он же не зря так и назван - Лайв!) Разработчики его люди очень упертые, Они свою концепцию ради какой-то там загрузки АСИО не сменят.
"Можно ли с мака перейти на PC и не глупо ли это?" )) Можно. Все зависит от софта, который собираетесь юзать. Я пользую Лайв на макбук про. На студийном PC (более мощном) Лайв и Самплитуда. Вся система продумывалась сразу (перед тем, как брать железо). Еще раз повторюсь - все зависит от программ вашего предпочтения. С этого надо начинать собирать комп. А не наоборот)

 

[ar-T]

Aleksandr_Oleynik, извиняюсь, не осилил все страницы, может уже и было здесь..,
1- нужно отключить парковку ядер в винде, http://tv-22.ru/optimizaciya-raboty-fl-studio-pod-win7-i-mnogoyadernymi-processorami.html/
2- в драйвере для нвидии нужно отключить powermizer http://nvworld.ru/faq/disable-powermizer/, но тогда будет фиксированная частота- больше нагрев..., я как то пробовал ещё давно, все проблемы с dpc от видеодрайвера пропадают..., но нагрев меня не устраивает поэтому вернул обратно.., тут уж компромисс.., что важнее..

 

[Aleksandr Oleynik]

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

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

 

[Aleksandr Oleynik]

Aleksandr_Oleynik, извиняюсь, не осилил все страницы, может уже и было здесь..,
1- нужно отключить парковку ядер в винде, http://tv-22.ru/optimizaciya-raboty-fl-studio-pod-win7-i-mnogoyadernymi-processorami.html/
2- в драйвере для нвидии нужно отключить powermizer http://nvworld.ru/faq/disable-powermizer/, но тогда будет фиксированная частота- больше нагрев..., я как то пробовал ещё давно, все проблемы с dpc от видеодрайвера пропадают..., но нагрев меня не устраивает поэтому вернул обратно.., тут уж компромисс.., что важнее..

Не, ядра точно не паркуются - у меня винда 8.1 стоит, и когда была нвидиа, которую на АТИ сменил и рад этому, павер менеджер отключал - ноль на массу.

 

[ar-T]

Не, ядра точно не паркуются - у меня винда 8.1 стоит,

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

зы .. блин, я наоборот с хакинтошем заморочился чтоб мак ос юзать, а тут такое))

 

[Dmitry Stepin]

+1 к замене нвидии на ати. С АТИ забыл про существование каких-либо dpc задержек от видеодрайвера.

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

В кубике ж не приводит ни к чему из этого.

 

[Aleksandr Oleynik]

В кубике ж не приводит ни к чему из этого.

Быть такого не может. Как может быть так, чтобы на канале с включённым мониторингом была задержка больше, чем на канале рядом с выключенным и при этом не увеличилась общая задержка для синхронизации?
Объясните как такое сделать хотябы теоретически.

 

[Aleksandr Oleynik]

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

Я использую Рипер и он ОЧЕНЬ сильно сам при загрузке оптимизирует под свои задачи операционку и ASIO.
Ну и мои проверки эффективности Гипертрэйдинга привели к тому, что я его отключил, так что нечему там парковаться - распарковываться.
Но я посмотрел - в моих настройках в менеджменте Питания на CPU опциях везде стоит 100%

 

[ar-T]

так что нечему там парковаться - распарковываться.

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

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

вот так должно быть
Посмотреть вложение 94782

 

[Dmitry Stepin]

Как может быть так, чтобы на канале с включённым мониторингом была задержка больше, чем на канале рядом с выключенным

Наоборот, на канале с включенным мониторингом реальная задержка АСИО, а на остальных каналах без мониторинга задержка АСИО+добавочный буфер. А в чем проблема-то? Почему рассинхронизация должна быть? Вы включаете воспроизведение, и слышите канал с мониторингом с минимальной задержкой, но играете под то, что звучит с асио+добавочный буфер.

 

[Aleksandr Oleynik]

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

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

вот так должно быть
Посмотреть вложение 94782

Так оно ТАК по умолчанию в Win 8.1 в High Performence.
Ну и НИ РАЗУ, при любых настройках операционки, не видел чтобы в Рипере не до гружались какие-то ядра - всё грузится поровну.

 

[Aleksandr Oleynik]

Наоборот, на канале с включенным мониторингом реальная задержка АСИО, а на остальных каналах без мониторинга задержка АСИО+добавочный буфер. А в чем проблема-то? Почему рассинхронизация должна быть? Вы включаете воспроизведение, и слышите канал с мониторингом с минимальной задержкой, но играете под то, что звучит с асио+добавочный буфер.

Хм..... нужно переосмыслить. В общем, конечно, такое может быть.
Как только проверить это?
Но в общем-то, если я на токое поведение DAW повлиять ни как не могу - то и разбираться особо смысла нет.
В Рипере достаточно много не совсем очевидных настроек, которые в той или иной степени влияют на Общую Эффективность Системы при малых задержках.
Я для себя опытным путём нащупал оптимальные настройки и их использую.