Слабое звено между DAW ASIO протоколом передачи данных и железом ПК

AE Ezhkov

AE Ezhkov

Member
7 Ноя 2023
70
17
8
Тема, как я считаю, злободневная и актуальная.
Внятного, полного и достоверного ответа на вопрос о слабом звене в цепи ПК/ПРОТОКОЛ/Интерфейс/ASIO/DAW я не получил и не нашёл на ветках форума.

Моя гипотеза и суть вопроса - может ли протокол передачи данных, влиять на производительность всего конфига, стабильность работы системы и на максимальное количество стабильно работающих(Без тресков, фризов, подвисаний и отвала аудио) в проекте VST ?

Если нет, где искать слабое звено?

Короче, короче не получится XD


Условия и кофиг мной проведенного теста:

ПК-Thinkpad P52

i7 8850H 2.6 - 4.3 ГГц
6 ядер / 12 потоков
(4.1 ГГц для 4 активных ядер, 4 ГГц макс. при активности всех 6 ядер)
Кэш 1-го уровня64K (на ядро)
Кэш 2-го уровня256K (на ядро)
Кэш 3-го уровня12 Мб (всего)

DDR 4 -16 GB
M2 512gb
Thunderbolt3 port
USB port

Интерфейс - Audient Sono
работающий по протоколу USB2.0
24-бит / 96 кГц

ASIO от компании audient

DAW - Cubase 12.5

Референсный плагин для нагрузки системы- sooth2 (Х4 ULTRA)



У себя на студийке запускаю кубик , создаю пустой проект
Cоздаю дорожку и в инсерты кидаю четыре/пять суфа на максималках.
Вижу предельную нагрузку в ASIO Guard. (Отвал звука и томоза свей системы)
Открываю настройки ASIO в Cubase и вижу что мультипроцессиг работает.
Открываю монитор ресурсов ПК и вижу что используется четверть мощностей CPU, то есть проц загружен на 20-25% , память и того меньше.
Буфер в асио драйвере , в интерфейсе AUDIENT при том-4096 семплов
24 бита
96 000Кг

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

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

У него по конфигу

ПК на i7 7700K
4 ядра / 8 потоков
4.2 ГГц и 4.5 в режиме Turbo;
Кэш 1-го уровня64K (на ядро)
Кэш 2-го уровня256K (на ядро)
Кэш 3-го уровня8 Мб (всего)
DDR4 - 16GB
M2 512gb
Thunderbolt

Интерфейс - Motu M2 работающий по протоколу Thunderbolt

DAW cakewalk

Создаем новый проект
Cоздаём дорожку и в инсерты кидаем четыре/пять суфа на максималках.
Видим предельную нагрузку в ASIO и всё заскрежетало, отвал звука и вот это всё.
Хмм...
Открываем настройки ASIO и видим буфе - 32 семпла
Sample Rate 48000 Гц 24 бита
Открываем монитор ресерсов ПК и видим что проц загружен на 20-25 %

Меняем размер буфера на 512 и вуаля, пошла нагрузка на проц
Ставим размер буфера еще больше-1024 и нагрузка на CPU растет,
Соответственно нагрузка с ASIO падает.

Единственное радикальное различие в обоих конфигах- протокол связи.

Пьём чай, курим и потихоничку приходим к мнению что именно протокол является слабым звеном.
По тому как USB2.0 просто не в состоянии пропустить большое количество инфы, а Thunderbolt - вполне.


Этот же тест я проводил еще на схожем по конфигу ПК.
Только давненько и у другого моего товарища, на карте Steinberg UR44C .
Там тоже протокол USB а не Thundaerbolt.
И юзался тот же, в данном случае референсный soothe2, в том же количестве четырех/пяти штук.
Он и там критически нагрузил ASIO в кубейсе 10,5 и совершенно не нагрузил CPU.

Да, ещё решил ещё спросить у Ильи Лукашева., т.к у чела экспа есть и топовое оборудование есть.
-Ответил, цитирую :

"Здравствуйте. Протокол никак не влияет на производительность. На производительность влияет мощность процессора, его тактовая частота, а так же косвенно - размер процессинг буффера "

У меня большие сомнения по этому поводу.

Только опытным путем мне удалось как-то передать нагрузку с ASIO или DAW на CPU,
И ведь MOTU M8 работала именно по протоколу Thunderbolt и увеличением буфера удалось прямо пропорционально( или почти) передать нагрузку на ЦП. И протокол- это единственное существенное различие в кофиге.

Полагаю что DAW , сама по себе, так радикально на это не может повлиять, будь то кубик, риппер или еще что.
Карта сама по себе на работу плагина не влияет, только если карта с DSP , а VST специально под нее написаны.
Хотя , скажем AUDIENT SONO и Steinberg UR44C +- из одной категории, настольные и компактные
А MOTU M8, из другой , рэковая .

У кого какие мысли, доводы и факты по данному вопросу?
Буду рад обоснованным ответам и личным наблюдениям.



Знатоки, в Студию!
 
  • Haha
Реакции: presly и basЫl
Старо как мир и все неправильно , протокол тут не причем совершенно ...)
а причем его конкретная реализация на данном конкретном аудиоинтерфейсе .

1 - Есть такое понятие как LLP - low latency perfomance ) и я могу сходу вам назвать usb интерфейс который сходу уберет вашу моту по той самой загрузке ASIO - babyface pro FS )) или бюджетный Zoom uac2 )
Пропускной способности usb даже версии 2.0 хватает за глаза для любого аудио с кучей каналов ,а уж 3.0 хватает с большим запасом )
А sono - если мне не изменяет память использует OEM драйвер от Thesyon.de с соответствующей реализацией на чипе - , который в плане работы с асио - всегда был унылым говном ))) тем не менее его используют и бехры , и audient и еще много кто , и даже SSL )

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

Так что если хотите хоть как то связать асиометр с загрузкой проца , смотрите поядерно на одно из ядер на котором наибольшая загрузка пиком присутствует...

3 - тесты от DAWBENCH всех известных науке аудиоинтерфейсов с производительностью LLP и тут и на GS лежат уже лет наверное 15 ) ...и обсасывалось это все столько раз , что я просто ума не приложу - как можно было быть не в курсе)

И там - никакой прямой корреляции между протоколом и производительностью интерфейса в ASIO нет , есть говенные и PCI-e и thunderbolt и firewire интерфейсы, а есть отличные USB )

А вот связь с производителями самих устройств прямая, - потому что все первые строчки в чартах отданы RME ) которые всегда писали свои дрова для своих разработок , не халтурили в этом смысле , ..и не использовали OEM решения от сторонних производителей - как в вышеописанном случае с audient sono )

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

и тут важно не то сколько у вас там условных Soothe а то как они стоят в DAW - на разных каналах ) или на одном ) или куча на подгруппе )
Даже с огромным буфером вы легко можете ( при определенных условиях ) посадить на жопу одно ядро проца и получить 20 процентов загрузки общей CPU - (которая в windows считается усредненно ) и зашкал асио метра )
Потому что планировщики многоядерности в DAW так устроены ) ... Они все работают с приоритетами ..
 
Последнее редактирование:
  • Like
  • Love
Реакции: itzh, Antonio, kostyaline и 8 других
AE Ezhkov написал(а):
а так же косвенно - размер процессинг буффера
Нажмите для раскрытия...
Не косвенно, а в общем-то напрямую, если знать принципы работы нейтивных систем на нереалтаймовых ОС "общего назначения", каковыми являются обычные Вин и МакОС. Которые перегружены кучей вспомогательных задач, не имеющих отношения к работе со звуком, и постоянно "дёргающими" проц под свои нужды. При таком сценарии процу легче обрабатывать большие пакеты данных, чем постоянную череду мелких пакетов. По аналогии бочка с водой наполнится быстрее, если носить воду из крана ведром, а не бегая с наполненными ладошками туда-сюда (с риском расплескать гораздо больше). Это один аспект.

А другой довольно внятно был описан здесь:

RME Babyface Pro — USB интерфейс 4х4 с аппаратными эффектами | ProSound

prosound.ixbt.com prosound.ixbt.com

Изначально интерфейсы RME появились как альтернатива традиционному подходу тех же M-Audio, когда берётся готовый цифровой чип стороннего производителя и на него вешается несколько цифровых и аналоговых каналов. Драйвер берётся готовый, от производителя чипа. Минус в том, что разработчики чипов имеют смутное представление о задачах музыкантов, а какой-нибудь абстрактный M-Audio при всём желании не может повлиять на поставщика чипов. В итоге, задачи музыканта или работника вещания в расчёт вообще не берутся. Нельзя создать устройство под конкретную задачу и нельзя добавить ни одну дополнительную функцию. Также, если для внутреннего цифрового микширования используется DSP, то всегда будет возникать большая задержка прохождения сигнала. Это ещё не так страшно для студии звукозаписи, хотя и там это радости не вызывает. Но для вещателей вообще не приемлемо, так как возникает непредсказуемая рассинхронизация видео и звука.

Интерфейсы RME с самого начала выступили антиподом всех существующих недорогих (по профессиональным меркам) решений. В архитектуре любого интерфейса RME лежит FPGA. Это программируемая транзисторная матрица, логику работы которой на 100% определяет пользователь, а не производитель чипа. FGPA обладает неограниченной гибкостью по маршрутизации сигнала и нулевой задержкой прохождения сигнала, даже если нужно обработать сотню каналов одновременно. В FPGA такая обработка будет параллельной и мгновенной, так как нет очереди команд и памяти, как в традиционных DSP. То есть сигнал проходит быстрее в тысячу раз, с нулевой задержкой на обработку. Минусы FPGA - трудоёмкость разработки железа и драйверов, высокая себестоимость. Очевидно, что мало смысла применять FPGA, если стоит стандартная задача записать и воспроизвести 2 канала. Хотя и здесь возможен выигрыш, если нужна более высокая стабильность работы, так как компания RME сама разрабатывает драйвера и имеет больше возможностей их отладить.
Нажмите для раскрытия...

Т.е. абсолютному большинству производителей интерфейсов, включая "топов" типа Prism, влом (или накладно) разрабатывать кастомные USB чипсеты, заточенные под ввод/вывод аудио, и писать "с нуля" оптимизированные под них дрова, и они использут вместо них некие "generic" решения "общего назначения", слегка допиленные напильником (и то не всегда) под конкретный продукт. Отсюда и разочаровывающий во многих случаях результат.
 
  • Like
  • Love
Реакции: itzh, Long, Ludwid и 2 других
Alex_HS написал(а):
Которые перегружены кучей вспомогательных задач, не имеющих отношения к работе со звуком, и постоянно "дёргающими" проц под свои нужды
Нажмите для раскрытия...
Даже если исключить все эти задачи , по большому счету ничего не изменится , потому что данные ОС не являются ОС реального времени ) ...

А разработка чистой ОСРВ - под музыкальные задачи тоже слабореализуема - потому что ОСРВ - детерминированы )..
Потому в параллельной вселенной - где все население состоит из мюзикмейкеров , это была бы гибридная ОС сочетающая в себе классическую и ОСРВ по части ввода вывода ) что тоже не так просто но теоретически реализуемо ..
Но в нашей вселенной такой объем работы - совершенно лишен как практического так и коммерческого смысла - даже теоретически)
Потому что даже линукс всем известный ..и много лет везде использующийся, так и не стал для музыки )

на самом деле весь этот "мусор " в ОС , современным процам до лампочки , мой 5950x в винде где висят куча вкладок в хроме , всякие антивирусы
полезные проги и т д .. постоянно пребывает в блаженной неге , с частотой 400 мгц ) и с практически нулевой загрузкой процессора)
Но мы забываем про то что "под капотом " , а это система ввода вывода ....а это тонны разнообразных устройств в современном пк , и куча драйверов к ним - многие из которых работают с высокими приоритетами ввода вывода ...)
И вот от этого уже не избавишься никак , потому работать с DAW без видеокарты , SSD . USB портов и жестких дисков - оч затруднительно :)
А окошко к процу на процессы time critical , и с высоким приоритетом - не резиновое )

Вот там ASIO и спотыкается) потому что единственный способ прям уравнять асио метр с загрузкой цпу )
Это какой нить стандарт VST4 - в который уже на уровне базового кода будет заложен мультипроцессинг на все возможные ядра ...
и любые плаги поддерживающие его , будут раскидываться автоматом...
 
Последнее редактирование:
  • Like
Реакции: itzh, 02_Goliaf и max-owl
Zerocool написал(а):
это была бы гибридная ОС сочетающая в себе классическую и ОСРВ по части ввода вывода ) что тоже не так просто но теоретически реализуемо ..
Нажмите для раскрытия...
Реализовано в MassCore у Pyramix, но очень дорого даже по софтовой части, требует своих интерфейсов (самый дешёвый из которых Merging Anubis ЕМНИП) и не поддерживает софтовые плаги-инструменты (только обработки собсного формата vs3). Зато делает всего из 2-х изолированных от "управляющей" системы (Win) ядер банального Core i5 мощнейшую DSP-систему, с 384-канальным микшером на "стандартных" частотах 44/48, с плагинами обработки и околонулевыми задержками. На современных уже существующих процах можно было бы "межгалактический пепелац" запустить.

Zerocool написал(а):
Но в нашей вселенной такой объем работы - совершенно лишен как практического так и коммерческого смысла - даже теоретически)
Нажмите для раскрытия...
К огромному сожалению, но факт! :Dle80:
 
  • Like
  • Haha
Реакции: itzh, dromax и 02_Goliaf
в очередной раз добавлю, что всякие асио-метры - ЭТО НЕ ЗАГРУЗКА ПРОЦА!
Это секундомер, который показывает отношение времени обработки всего буфера всех плагинов на всех треках ко времени самого буфера.
Частично оно зависит от частоты проца (можно сказать грубая однопоточная скорость), НО:
- так как все проги работает в так называемом User-space, то все что в нем находится, имеет приоритет ниже чем самый всратый железный драйвер в системе. И вы можете разогнать проц до 10ГГЦ, охладив сердцем бывшей, но если системе потребуется пошарить например по локальной сетке - все ваши задачи встанут в сторонку по причине опроса сетевого стека.
На древних тачках такое можно было наблюдать во время опроса флоппи-диска.
- второй фактор - распараллеливаемость кода плагина. У вас может быть заряжен мультиголовый AMD EPIC, но если плаг написан в однопоток, то пока он не обработается одним ядром, следующие плаги будут курить. Скорость каравана ограничена самым медленным верблюдом.
- побочный фактор: Маркетинговая турбо частота. Это частота на микропериод когда проц просто не успевает раскалиться. А стабильная работа - это базовая частота проца.
237196



Драйвера карты вообще не причем!
Успел буфер обработаться внутри DAW или нет - происходит ДО попадания в буфер карты (в случае аудиовыхода).
 
  • Like
Реакции: 02_Goliaf
Zerocool написал(а):
Старо как мир и все неправильно , протокол тут не причем совершенно ...)
а причем его конкретная реализация на данном конкретном аудиоинтерфейсе .

1 - Есть такое понятие как LLP - low latency perfomance ) и я могу сходу вам назвать usb интерфейс который сходу уберет вашу моту по той самой загрузке ASIO - babyface pro FS )) или бюджетный Zoom uac2 )
Пропускной способности usb даже версии 2.0 хватает за глаза для любого аудио с кучей каналов ,а уж 3.0 хватает с большим запасом )
А sono - если мне не изменяет память использует OEM драйвер от Thesyon.de с соответствующей реализацией на чипе - , который в плане работы с асио - всегда был унылым говном ))) тем не менее его используют и бехры , и audient и еще много кто , и даже SSL )

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

Так что если хотите хоть как то связать асиометр с загрузкой проца , смотрите поядерно на одно из ядер на котором наибольшая загрузка пиком присутствует...

3 - тесты от DAWBENCH всех известных науке аудиоинтерфейсов с производительностью LLP и тут и на GS лежат уже лет наверное 15 ) ...и обсасывалось это все столько раз , что я просто ума не приложу - как можно было быть не в курсе)

И там - никакой прямой корреляции между протоколом и производительностью интерфейса в ASIO нет , есть говенные и PCI-e и thunderbolt и firewire интерфейсы, а есть отличные USB )

А вот связь с производителями самих устройств прямая, - потому что все первые строчки в чартах отданы RME ) которые всегда писали свои дрова для своих разработок , не халтурили в этом смысле , ..и не использовали OEM решения от сторонних производителей - как в вышеописанном случае с audient sono )

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

и тут важно не то сколько у вас там условных Soothe а то как они стоят в DAW - на разных каналах ) или на одном ) или куча на подгруппе )
Даже с огромным буфером вы легко можете ( при определенных условиях ) посадить на жопу одно ядро проца и получить 20 процентов загрузки общей CPU - (которая в windows считается усредненно ) и зашкал асио метра )
Потому что планировщики многоядерности в DAW так устроены ) ... Они все работают с приоритетами ..
Нажмите для раскрытия...
Во первых, спасибо за ответ, во вторых - дык какой главный критерий для стабильной работы системы в заданных условиях? Правильно и коректно прописанные ASIO дрова?
Если шо, я новичок) И на форуме впервые, а об остальных даже не знаю
 
basЫl написал(а):
в очередной раз добавлю, что всякие асио-метры - ЭТО НЕ ЗАГРУЗКА ПРОЦА!
Это секундомер, который показывает отношение времени обработки всего буфера всех плагинов на всех треках ко времени самого буфера.
Частично оно зависит от частоты проца (можно сказать грубая однопоточная скорость), НО:
- так как все проги работает в так называемом User-space, то все что в нем находится, имеет приоритет ниже чем самый всратый железный драйвер в системе. И вы можете разогнать проц до 10ГГЦ, охладив сердцем бывшей, но если системе потребуется пошарить например по локальной сетке - все ваши задачи встанут в сторонку по причине опроса сетевого стека.
На древних тачках такое можно было наблюдать во время опроса флоппи-диска.
- второй фактор - распараллеливаемость кода плагина. У вас может быть заряжен мультиголовый AMD EPIC, но если плаг написан в однопоток, то пока он не обработается одним ядром, следующие плаги будут курить. Скорость каравана ограничена самым медленным верблюдом.
- побочный фактор: Маркетинговая турбо частота. Это частота на микропериод когда проц просто не успевает раскалиться. А стабильная работа - это базовая частота проца.
Посмотреть вложение 237196


Драйвера карты вообще не причем!
Успел буфер обработаться внутри DAW или нет - происходит ДО попадания в буфер карты (в случае аудиовыхода).
Нажмите для раскрытия...
Ну как же нипричем? А кто тогда слабое звено в цепи? Давайте конструктивно
 
AE Ezhkov написал(а):
Ну как же нипричем? А кто тогда слабое звено в цепи? Давайте конструктивно
Нажмите для раскрытия...

Не причем в случае большого буфера ) потому что как я говорил выше , при буфере выше 512 семплов они все плюс минус одинаково работают )
А ниже да - LLP )
 
AE Ezhkov написал(а):
А кто тогда слабое звено в цепи?
Нажмите для раскрытия...
Если говорить про систему в целом (если нужна хорошая производительность без щелчков), то всё вместе влияет. То есть, даже имея хорошую производительность по asio, и мощный процессор, можно получить проблемы просто из за неправильных настроек энергопотребления.
А поскольку каждая система уникальна, нет и единого решения. Разве что, можно придумать алгоритм поиска и решения проблемы.
 
basЫl

Кстати я делал такой трюк , аномально жрущему плагу от NDSP через process hacker находил его в дочерних процессах запущенной DAW и вручную менял ему приоритет на высокий ...и загрузка асио снижалась втрое ).. по асиометру..

Так что то как DAW обходятся с процессами - тоже еще большой вопрос )
 
  • Wow
  • Like
Реакции: kostyaline, 02_Goliaf и «G~Li†ch»
@AE Ezhkov, у вас в первом случае ноутбук с разными энергосберегающими функциями, во втором десктоп. Работа со звуком очень не любит плавающей производительности. К тому же 7700К производительнее 8850Н судя по беглому просмотру тестов, в однопотоке точно. Важно и общее состояние системы и драйверов. Важным моментом является работа DPC, а кривой драйвер вайфая или видеокарты может резко увеличивать потребление процессорного времени и для работы с аудиодрайвером его остается меньше, как пример видеокарты AMD по этому параметру лучше чем Nvidia. Надо бы посмотреть что там LatencyMon увидит. К слову DAW у вас разные, что думаю тоже может иметь значение.
 
Zerocool написал(а):
Так что то как DAW обходятся с процессами - тоже еще большой вопрос )
Нажмите для раскрытия...
это кстати тоже большое ДА, и не только с процессами.

когда DAW Отдает на обработку любое число семплов (не равное размеру буфера, не равное хотя бы степени двойки, а вообще любое рандомное число семплов) - тут возникает горячее желание бить таких обезьянокодеров молотком по пальцам.
чтобы обработать 129 семплов, надо потратить времени вплоть до 256 семплов времени в грубом подсчете.
 
basЫl написал(а):
огда DAW Отдает на обработку любое число семплов (не равное размеру буфера, не равное хотя бы степени двойки, а вообще любое рандомное число семплов) - тут возникает горячее желание бить таких обезьянокодеров молотком по пальцам.
Нажмите для раскрытия...
А кто так делает?
 
Zerocool написал(а):
Merging это не ОСРВ )
Нажмите для раскрытия...
Насколько я понимаю - при использовании Масскора там работают одновременно 2 ОС - Вин для интерфейсных дел и RTOS (на изолированных от Винды ядрах) для ввода/вывода/обработки звуковых потоков.
 
  • Wow
Реакции: belovw
@N0-body,

я не буду называть. Все отслеживается, интернет маленький.
Но по самому стандарту VST плагин должен иметь возможность обрабатывать любое количество входных семплов. Это все конечно здорово, когда отправляешь 1 или 7 или 9 или 17 семплов и железка радостно и мгновенно их обрабатывает. Но сейчас это могут делать только лишь DSP, что будет дорого когда их потребуется сто.
 
Aмирханов написал(а):
Измени условия. Купи rme
Нажмите для раскрытия...
В принципе, я уже смирился с тем что достаточно "свежий" интерфейс от Audient, в лице Sono, хорошо справляется с записью, но совершенно беспомощен в работе над проектом.
Вижу что это вообще не тот инструмент , который мне нужен и ощущаю.
RME, со слов очевидцев, не так интуитивно понятен по управлению и для меня может быть избыточен, ввиду непонимания некоторых нюансов .
Сделаю небольшое отступление и скажу что "настолько" погрузиться в тему мне ещё не доводилось, но чем выше мои аппетиты при работе с проектами, тем больше я понимаю что это необходимо развиваться, аппаратно в том числе)
Мой бэкграунд не настолько велик чтоб знать все тонкости и нюансы, потому я здесь и мне приятно видеть компетентных людей)
Я набираюсь опыта и нужной информации, то бишь в процессе обучения.

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

Но ответы породили новый вопрос,

-Че покупать то XD ?

Хочется и рыбку покушать и пивка попить XD Чтоб с перспективой на рос и по бэкраунду мне подошла, а не загнала меня ещё глкбже в форумы и мануалы)

Думается мне создать тему - Best low latensy perfomance Raiting 2023

Потому как те данные по производительным и оптимизированным интерфейсам, которые есть в сети, они уже устарели...
 
Oliver_Cray написал(а):
@AE Ezhkov, у вас в первом случае ноутбук с разными энергосберегающими функциями, во втором десктоп. Работа со звуком очень не любит плавающей производительности. К тому же 7700К производительнее 8850Н судя по беглому просмотру тестов, в однопотоке точно. Важно и общее состояние системы и драйверов. Важным моментом является работа DPC, а кривой драйвер вайфая или видеокарты может резко увеличивать потребление процессорного времени и для работы с аудиодрайвером его остается меньше, как пример видеокарты AMD по этому параметру лучше чем Nvidia. Надо бы посмотреть что там LatencyMon увидит. К слову DAW у вас разные, что думаю тоже может иметь значение.
Нажмите для раскрытия...
Извольте сударь, я ведь и третий пример привёл, где конфиг ПК , как в случае с моим первым другом.
То есть +- две машины с одинаковой производительностью , но каты разные и протоколы.
Motu 8M и Steinberg UR44C , в первом случае был THNBLT а во втором USB 2.0
Плагин юзал тот же Sooth, DAW cubase 10.5
И в случае второго ПК(Steinberg UR44C USB2.0) Все было тоже оч печально в работе системы и так же как и у меня, нагрузка на CPU отсутствовала
 
AE Ezhkov написал(а):
В
RME, со слов очевидцев, не так интуитивно понятен по управлению и для меня может быть избыточен, ввиду непонимания некоторых нюансов .
Нажмите для раскрытия...
если не понимаете нюансов как заключили что может быть избыточным?
 
Zerocool написал(а):
Не причем в случае большого буфера ) потому что как я говорил выше , при буфере выше 512 семплов они все плюс минус одинаково работают )
А ниже да - LLP )
Нажмите для раскрытия...
В моем случае нет
Aмирханов написал(а):
если не понимаете нюансов как заключили что может быть избыточным?
Нажмите для раскрытия...
Со слов юзеров , которые на этот интерфейс перешли, с чего-то более простого и доступного
 
Войдите или зарегистрируйтесь для ответа.

Сейчас просматривают

Всего: 1 (пользователей: 0, гостей: 1)
Сверху Снизу