Очень хорошая масштабируемость инстанций. На интеле разница между первой и последней инстанцией (% нагрузки) на много больше
AMD Ryzen для DAW (2 онлайн)
- Автор темы Pavell
- Дата начала
- Статус
@Aleksandr Oleynik, гхмм..., а для музыкантов? ) Что это значит?
[DOUBLEPOST=1496943176][/DOUBLEPOST]@Александр32
Процессор - AMD Ryzen7 1700 (разогнан до 3.8)
Кулер для процессора- Noctua NH-U12S SE-AM4
Материнская плата - ASUS PRIME B350-PLUS
Оперативная память- Samsung DDR4 - 8Гб 2400 (временно в ожидании новой ASEGA)
Жесткие диски - WD Caviar Black - 2 шт.
SSD - 120 ГБ Kingston V300
Блок питания - Chieftec Force 500W
Видеокарта - GeForce GT 610 (пассивная)
Корпус - Thermaltake Suppressor F51
Операционная система - Windows 10 Enterprise 2016 (64) LTSB
Звуковая карта - Creamware Scope Professional 5.1 (64)
Хост - Cubase 8.0 (64)
[DOUBLEPOST=1496943176][/DOUBLEPOST]@Александр32
Процессор - AMD Ryzen7 1700 (разогнан до 3.8)
Кулер для процессора- Noctua NH-U12S SE-AM4
Материнская плата - ASUS PRIME B350-PLUS
Оперативная память- Samsung DDR4 - 8Гб 2400 (временно в ожидании новой ASEGA)
Жесткие диски - WD Caviar Black - 2 шт.
SSD - 120 ГБ Kingston V300
Блок питания - Chieftec Force 500W
Видеокарта - GeForce GT 610 (пассивная)
Корпус - Thermaltake Suppressor F51
Операционная система - Windows 10 Enterprise 2016 (64) LTSB
Звуковая карта - Creamware Scope Professional 5.1 (64)
Хост - Cubase 8.0 (64)
Последнее редактирование:
Только то, что AMD Реально сделал наконец-то конкурента Интелу, больше ни чего
Ну вот теперь, картина проясняется, спасибо Павлу, и всем остальным. Я знаю что звуковая карта влияет на показания процессора при разном буфере но не на столько сильно как то что получилось у меня на i5 2500К (NastyDLAmkII 10 штук )= 6,5% около того, против Ryzen7 1700 (NastyDLAmkII 10 штук )= 2,4%.
Но как человек пытливый, вкрадывается сомнение - "а может что-то упускаем" - а то результат аж в 3 раза бъет.
Но как человек пытливый, вкрадывается сомнение - "а может что-то упускаем" - а то результат аж в 3 раза бъет.
@Aleksandr Oleynik, а интересно, как у @Osman заиграло 24 Дивы?
[DOUBLEPOST=1496945015][/DOUBLEPOST]
[DOUBLEPOST=1496945015][/DOUBLEPOST]
На моем обычном буфере в 12 мс было в районе 1%.
@Pavell, а сделайте при плее своего проекта ( с 16-ю инстанциями и включённым Rec Arm на треках всех) скриншёт с RT CPU.
И совсем чтоб понимать ситуацию - запустите при этом плее LatencyMon, перейдите в закладку Driver и покажите - Highest execution
[DOUBLEPOST=1496946450][/DOUBLEPOST]
И совсем чтоб понимать ситуацию - запустите при этом плее LatencyMon, перейдите в закладку Driver и покажите - Highest execution
[DOUBLEPOST=1496946450][/DOUBLEPOST]
Это возможно, но при выключенных на треках Rec Arm .....20 тянет без потрескиваний
Так у него изначально частота выше
Так и думал, что из-за тактовой частоты.
Еще не все! Поменял настройки в Рипере, скрин внизу. Потянуло 20 инстанций Дивы без тресков, на 21 пошли трески. Но при включении Rec Arm, трещит.
[DOUBLEPOST=1496947139][/DOUBLEPOST]
Еще не все! Поменял настройки в Рипере, скрин внизу. Потянуло 20 инстанций Дивы без тресков, на 21 пошли трески. Но при включении Rec Arm, трещит.
[DOUBLEPOST=1496947139][/DOUBLEPOST]
Последнее редактирование:
@Pavell, Render-ahead смело ставьте вместо 200 - 15 ms (у вас в ASIO буфер 13 ms, всё что выше можно ставить) - шустрее будет реагировать на Play/Stop
Что касается Audio reading/processing threads - вообще-то там нужно ставить 8 для вашего проца, но как там на AMD работает Гипертрэйдинг - фиг его знает.....
Если с 16 становится лучше - то поставьте в Allow live FX multiprocessing on - 32 и в общем поиграйтесь с этой цифрой и понаблюдайте за CPU
[DOUBLEPOST=1496947635][/DOUBLEPOST]
Очень высокие значения DPC.
А сделайте этот же скриншот при плее тоже, но с минимально возможным буфером - 64 spl например
Что касается Audio reading/processing threads - вообще-то там нужно ставить 8 для вашего проца, но как там на AMD работает Гипертрэйдинг - фиг его знает.....
Если с 16 становится лучше - то поставьте в Allow live FX multiprocessing on - 32 и в общем поиграйтесь с этой цифрой и понаблюдайте за CPU
[DOUBLEPOST=1496947635][/DOUBLEPOST]
Вот этого я и боялся.
Очень высокие значения DPC.
А сделайте этот же скриншот при плее тоже, но с минимально возможным буфером - 64 spl например
Я не специалист и могу написать не верную терминологию и определения.
Но суть в том, что существует время за котолрое операционная система должна "посчитать" всё, что ей дают посчитать драйвера, в том числе и ASIO драйвер - и если время наиболшее для обработки какого то из драйверов больше чем 1/2 выставленного буфера в ASIO - будет срыв в звуке 100%.
Если у вас есть драйвера которые требуют 0,7 ms на обработку, значит выставить без глюков задержку менее 1,4 ms вы ни как не сможете - а по факту думаю эта величина в два раза ещё будет хуже.
У меня, к слову, максимальная величина - 0,1 ms - т.е. в 7 раз ЛУЧШЕ!
Так, на вскидку - AMD работает как MAC - MAC тоже на больших буферах, свыше 512 работает аналогично PC по производительности с Аудио, а вот на малых задержках СИЛЬНО сливает Интелу в PC.
Это да, известный факт про малые задержки AMD. Обсуждалось где-то здесь. Но я пользовался всегда 10 мс, очень редко 5-6. Так что, на моей работе это не сказывается.
Последнее редактирование:
Это критично для тех, кому нужен Лайв Риал Тайм от компа.
Для тех, кто работает с миди и вавками на треках - пофиг!
Aleksandr Oleynik, вы путаете и себя и народ ))
У вас непонятки с определениями )
Вы просто забираете у DAW возможность равномерно по времени и ядрам загрузить процессор.
При нормальном проигрывании - мы имеем "очередь" из данных, которые DAW знает заранее и "разруливает" ее - отдавая на обработку заранее и в нужные моменты, "размазывая" нагрузку во времени.
Но при включенной записи - DAW ничего не знает заранее.
Естественно поэтому для треков за напись не работают никакие "ASIO-Guard".
Само по себе это название - маркетинг. И не имеет отношения к ASIO! При этом - эта функция - нормальная и базовая для любого современного DAW. Только Штайнберги
решили выпендриться)))
И естественно, никакой буфер автоматом не выставляется (не считая просто дефолтного)
Ведь что значит "оптимальный"? Настройка буффера в своем принципе существует для того, чтобы пользователь выбирал между обработкой в (почти) реальном времени и производительностью.
Тут нет "оптимального" Есть разный для разных задач )
.
С таким же успехом, вы можете отключить кеширование диска, чтобы "понять его возможности" ))))
У меня на проекте @Pavell на 16-и инстанциях и при тех-же 512 spl буфере уже не в CPU проблема, а в RT CPU - в ASIO - оно до 90% доходит, а по опыту, если оно выше 60% - будут цифровые артефакты.[/QUOTE]
RT CPU не относится к ASIO!
Само ASIO здесь тоже не при чем.
Проще привести цитату, что такое RT CPU:
"....gives you an indication of how much leeway you have in processing. If you have anticipative FX enabled (and few tracks record armed), RT CPU will generally be pretty low, as most things should be done asynchronously, allowing the realtime thread to quickly put things together. "
Пространство для маневра - вот что это такое. Это просто более актуальный индикатор загрузки при работе со звуком.
И "ASIO" Вы называете некую абстрактную систему по своим понятиям.
А ASIO - это протокол. И реализация в драйверах и железе. И вся суть ASIO сводится к максимально прямой передаче данных между Software и Hardware.
Никаой "нагрузки на ASIO" не может быть по определению. Как не может быть "нагрузки на TCP/IP", например.
ё
Поэтому он и зашкаливает, даже если общий индикатор загрузки процессора невысок.
Вот например, количество голосов Spire на одной машине:
1-канальный режим памяти - 270 голосов
2-канальный - 370
3/4-х канальный - 480.
Или проводил условные тесты "сколько дорожек с одинаковым набором FX/VSTI выдержит без дропаутов"
1 планка памяти - в проекте до 12 дорожек до дропаутов
2 планки - 19 дорожек
3 планки - 21 дорожка.
При этом в зависимости от комбинации буффера 128-1024 и каналов памяти 1-4 на одной и той же системе получалось от 8 до 24 треков до начала дропаутов!
Разница в три раза!
У вас непонятки с определениями )
Ничего они не "создают", это простая математика - невозможно оптимизоровать то, что работает в реальном времени.
Вы просто забираете у DAW возможность равномерно по времени и ядрам загрузить процессор.
При нормальном проигрывании - мы имеем "очередь" из данных, которые DAW знает заранее и "разруливает" ее - отдавая на обработку заранее и в нужные моменты, "размазывая" нагрузку во времени.
Но при включенной записи - DAW ничего не знает заранее.
Естественно поэтому для треков за напись не работают никакие "ASIO-Guard".
Само по себе это название - маркетинг. И не имеет отношения к ASIO! При этом - эта функция - нормальная и базовая для любого современного DAW. Только Штайнберги
решили выпендриться)))
И естественно, никакой буфер автоматом не выставляется (не считая просто дефолтного)
Ведь что значит "оптимальный"? Настройка буффера в своем принципе существует для того, чтобы пользователь выбирал между обработкой в (почти) реальном времени и производительностью.
Тут нет "оптимального" Есть разный для разных задач )
ASIO - не про это, и об этом ниже.
.
С таким же успехом, вы можете отключить кеширование диска, чтобы "понять его возможности" ))))
У меня на проекте @Pavell на 16-и инстанциях и при тех-же 512 spl буфере уже не в CPU проблема, а в RT CPU - в ASIO - оно до 90% доходит, а по опыту, если оно выше 60% - будут цифровые артефакты.[/QUOTE]
RT CPU не относится к ASIO!
Само ASIO здесь тоже не при чем.
Проще привести цитату, что такое RT CPU:
"....gives you an indication of how much leeway you have in processing. If you have anticipative FX enabled (and few tracks record armed), RT CPU will generally be pretty low, as most things should be done asynchronously, allowing the realtime thread to quickly put things together. "
Пространство для маневра - вот что это такое. Это просто более актуальный индикатор загрузки при работе со звуком.
Банально - ваши артефакты - это перегруз по процу, несмотря на то, что он простаивает.
И "ASIO" Вы называете некую абстрактную систему по своим понятиям.
А ASIO - это протокол. И реализация в драйверах и железе. И вся суть ASIO сводится к максимально прямой передаче данных между Software и Hardware.
Никаой "нагрузки на ASIO" не может быть по определению. Как не может быть "нагрузки на TCP/IP", например.
ё
У вас "сливает" не ASIO, а RT индикатор, который показывает, что пространства для маневра у вас мало, потому что какой-то один (или много) процессов требуют в какие-то моменты непосильно много ресурсов.
Поэтому он и зашкаливает, даже если общий индикатор загрузки процессора невысок.
Да вы просто не могли этого "наблюдать", не делая специальные исследования. Как раз в НАШЕМ деле это влияение наиболее заметно. Я лично проводил множество тестов на разных машинах.
Вот например, количество голосов Spire на одной машине:
1-канальный режим памяти - 270 голосов
2-канальный - 370
3/4-х канальный - 480.
Или проводил условные тесты "сколько дорожек с одинаковым набором FX/VSTI выдержит без дропаутов"
1 планка памяти - в проекте до 12 дорожек до дропаутов
2 планки - 19 дорожек
3 планки - 21 дорожка.
При этом в зависимости от комбинации буффера 128-1024 и каналов памяти 1-4 на одной и той же системе получалось от 8 до 24 треков до начала дропаутов!
Разница в три раза!
Последнее редактирование:
Это как раз худший вариант для Ryzen ) Ведь память 3200 уже дает 15% (поправьте меня?) с ходу. Если память будет еще и двухканальной...
Т.е. ваш тест - показывает, что Ryzen даже в самой невыгодной позиции показывает себя очень хорошо!
Вы можете ставить и большее значение. Это простая математика: скорость звука - 330 м/c. 10 миллисекунд - это 3.3 метра от источника звука. Вы вряд-ли ощутите эту задержку.
Если вы не играете в реальном времени, то вся разница для вас будет в том, что, как сказал Aleksandr Oleynik, "шустрее будет реагировать на Play/Stop"
Последнее редактирование:
@profyart, то что у меня есть не понятки с определениями - я не скрываю.
То, что ASIO это просто протокол в общем-то знаю конечно и что на прямую RT CPU к ASIO (или Core Audio) отношения не имеет, тоже понимаю. Но для упрощения так уж приняло здешнее сообщество - что RT CPU - это показатель загрузки канала ввода и вывода звука.
Да и в Кубе аналогичный индикатор тоже почему-то же назвали - ASIO Time Usage.
За то, что уточняете и поясняете (видимо понимая то, о чём пишите) - огромное спасибо.
Теперь бы ещё разобраться в конкретных действиях для повышения производительности DAW.
Я пробовал играться с памятью - на моих компах эти игры давали нулевой результат.
Может поможете разобраться практически? На примере например моей системы....
PS: И ещё вопрос - что такое Реальное Время?
Ну вот что обозначает, что тот или иной плагин не имеет вообще задержки (буфер = 0)?
На сколько я понимаю, для звука всё что быстрее времени равного одному сэмплу = реальному времени?
То, что ASIO это просто протокол в общем-то знаю конечно и что на прямую RT CPU к ASIO (или Core Audio) отношения не имеет, тоже понимаю. Но для упрощения так уж приняло здешнее сообщество - что RT CPU - это показатель загрузки канала ввода и вывода звука.
Да и в Кубе аналогичный индикатор тоже почему-то же назвали - ASIO Time Usage.
За то, что уточняете и поясняете (видимо понимая то, о чём пишите) - огромное спасибо.
Теперь бы ещё разобраться в конкретных действиях для повышения производительности DAW.
Я пробовал играться с памятью - на моих компах эти игры давали нулевой результат.
Может поможете разобраться практически? На примере например моей системы....
PS: И ещё вопрос - что такое Реальное Время?
Ну вот что обозначает, что тот или иной плагин не имеет вообще задержки (буфер = 0)?
На сколько я понимаю, для звука всё что быстрее времени равного одному сэмплу = реальному времени?
Последнее редактирование:
Да, так и есть, производительность Ryzen сильно зависит от частоты памяти. Я пока взял временный вариант, в ожидании AGESA 1.0.0.6, в которой заявлена поддержка памяти до 4000. Уже есть бета нового биоса на мою материнку, но я жду офф. релиз. В планах 2 Х 16 3400 и выше или 4 х 8, т.к. 64 Гига оперативки, думаю будет излишни.
Кстати память, что я сейчас использую M378A1K43BB1 на b-die чипах, хорошо гонится до 3200 и выше. Но я пока оставил этот вопрос открытым. Тему по актуальной памяти для Ryzen отслеживаю.
Приятно слышать. )
@profyart, @Aleksandr Oleynik, я полагаю, что можно провести аналогию
CPU - RMS
RT CPU - Peak
Собственно во пояснение о создателя
CPU - RMS
RT CPU - Peak
Собственно во пояснение о создателя
@Oliver_Cray, а что такое audio thread servicing the sound device на понятном большинству языке? Как по мне - ASIO, хотя конечно я согласен с @profyart, и не только он об этом писал, что ASIO это всего лиш транспортный протокол и не более того.
@Aleksandr Oleynik, насколько я понимаю это сколько процессорного времени требуется на "техобслуживание" звуковой обработки. То есть если у вас загрузка RT CPU 50%, то половина мощности процессора расходуется на подготовку буфера и т.д.
Давайте призовем @Alf_Zetas может он прояснит лучше.
Давайте призовем @Alf_Zetas может он прояснит лучше.
Я выше намеренно опустил эту фразу про Servicing sound device в цитате - потому что она вводит путаницу.
Ведь ASIO начинается там, где заканчивается DAW. ASIO не участвует в разруливании и микшировании потоков в вашей DAW (вызов обработчиков, выстраивание очередей, балансирование нагрузки на ядра)
Задача ASIO - лишь передать данные от программы к аппаратной части с наименьшими задержками и наивысшим приоритетом.
Кроме того, DAW может выплевывать не только в ASIO - но и в другие сервисы-драйверы - MME, DirectSound
Поэтому мы и не можем говорить "потоки нагружают ASIO". В противном случае в сообществе создается устойчивое убеждение, что ASIO напрямую влияет на производительность, процессор и т.п. ))
И по поводу Servicing sound device:
И да и нет ))) Проблема в том, что люди часто пользуются уловностями и упрощениями, и это может вводить путаницу ) кроме того, учтите, что для многих английский - не родной, это вводит еще больше неразберихи.
Совершенно очевидно, что обслуживание поток не может кушать половину процессорного времени )
Приведу другую цитату:
"RT CPU is "Real Time CPU". It's the amount of CPU required in order to maintain real time audio. Thus, anything over 100% means audio drop outs. If your CPU can't do what is required within a specific time then it doesn't matter how much CPU is used"
А мы все испугались
Щас позовём! Если будет нужно - я и пива с ним могу попить
[DOUBLEPOST=1496998215][/DOUBLEPOST]Мне кажется, что тему нужно разделить, особенное если мы всё-же решим Разобраться и простым языком описать ситуацию со всеми этими вещами более-менее правильено и при этом понятно для большинства.
[DOUBLEPOST=1496998408][/DOUBLEPOST]
Но как и вы правильно заметили - дропауты появляются и при 50% RT CPU!
[DOUBLEPOST=1496998573][/DOUBLEPOST]
Об этом я много раз всем говорил - не нужно смотреть на то, что CPU загруженно только на 25%, смотрите как загружено RT CPU (в Рипере) или ASIO Time Usage у Стейнбергов (@profyart, вы видите КТО первый намутил с понятиями?).
И вот тут опять можно начать считать, что если вся мощность CPU это 100%, то если CPU = 70%, то для RT CPU остаётся всего 30% и если оно больше - дропауты?
И по поводу памяти. У меня стоит 32 гига DDR4-2666. Что ставить, чтоб поднять производительность в DAW?
Последнее редактирование:
http://www.scanproaudio.info/2017/03/02/amd-ryzen-first-look-for-audio/
Информация к размышлению. Все таки двоякое ощущение от Ryzen. Ведь по идее для работы с проектом можно оставаться и на старичке 2500К и работать с большим буфером, но как он покажет себя в реальном времени. ДА и разговор о якобы "дешевом" процессоре (как с заменителем сахара), что-то цены говорят об обратном.
Информация к размышлению. Все таки двоякое ощущение от Ryzen. Ведь по идее для работы с проектом можно оставаться и на старичке 2500К и работать с большим буфером, но как он покажет себя в реальном времени. ДА и разговор о якобы "дешевом" процессоре (как с заменителем сахара), что-то цены говорят об обратном.
Александр32 так это же по вашей ссылке старые тесты...да к тому же и не понятно что. Уже были после этого тесты на рабочей системе. Да и Павел вот все наглядно затестил. А если еще и с памятью быстрой....
Да и дешевый процессор это сколько для вас? Ryzen 1700 за 300$ это очень недорого. Особенно на фоне 6950x или планируемых i9. И будет еще дешевле после выхода ThreadRipper
Да и дешевый процессор это сколько для вас? Ryzen 1700 за 300$ это очень недорого. Особенно на фоне 6950x или планируемых i9. И будет еще дешевле после выхода ThreadRipper
К слову о цене (опять же смотря как будут гнаться две модели 1700 и 1700х) это 21000 и 28000 цены взяты из ДНС. Просто я если бы и взял то 1700Х просто из того что частота выше. В ситилинке дешевле конечно. Но 300 и 380 доляров тут не пахнет с нашими ценам.
- Статус