Хочу поменять Макбук на Винбук - смущает DPC Latency

  • Автор темы Автор темы maxo
  • Дата начала Дата начала
@Aleksandr Oleynik, @SoNick, Отключил Nvidia, ACPI батарею.
Если эти значения держутся и не прыгают выше - вполне себе нормальный результат.
[DOUBLEPOST=1549622161][/DOUBLEPOST]
Эпл вообще не парится на счёт dpc, так как у макоси такое понятие отсутствует как класс))
Думаю не отсутствует. А то, что нет инструмента посмотреть, так и на Винде бы не было, если бы не Resplendence.
Кстати, в ближайшее время будем с этим на Мак ОС и разбираться :)
 
Последнее редактирование:
@Dmitry Stepin, portcls.sys имеет отношение к звуку, но почему на 8.1 он ведёт себя пристойно на моём компе и выше 0.1 мс не поднимается и за два часа, а на Win 10, даже 1709, по любому за пол часа раз, другой скакнёт до 0,8 мс....
И это при использовании любой звуковухи.
 
Последнее редактирование:
  • Like
Реакции: SerGoL_81 и Никол
@Aleksandr Oleynik, кмк это из-за того что система управляет прерываниями, и w10 считает что какой-то девайс в определенный момент важнее, чем "какая-то звуковуха". Не знаю как на свежих мамках, но в старых был параметр "Plug and Play OS", который и отдавал контроль или оси, или биосу. Можно ещё поиграться с виртуальными прерываниями, есть утилитка MSI tool, может станет получше
 
  • Like
Реакции: Aleksandr Oleynik
@basЫl, спасибо, попробую.... эта проблема 100% связана с прерываниями. И она реально паршивая.
А что за утилита утилитка MSI tool? Я не нашёл.
 
Последнее редактирование:
@Aleksandr Oleynik,
еще обнаружил на ноуте, что в момент выхода HDD из спящего режима могут быть фризы
 
Эпл вообще не парится на счёт dpc, так как у макоси такое понятие отсутствует как класс))
Думаю не отсутствует.
DPC фича именно Windows, но именно этот механизм позволяет ей эффективнее работать в реальном времени.
 
@basЫl, все спящие режимы выключенны по оприори всегда
[DOUBLEPOST=1549736726][/DOUBLEPOST]@Oliver_Cray, и как же интересно на Мак Оси считаются любые процессы?
Не в буфере?
 
Сравнил.
Интересный результат.
RME MADI FX - PCI-Ex вообще отказалась нормалоьно работать в MSI mode
Ну и чуть пристальнее посмотрел в общем на ситуацию - все драйвера, кроме того, который участвует как выбранный в качестве Аудио утсройтва - DPC держится до 0,06 мс - а вот драйвер отвечающий за работу выбранного Аудио девайса - в течении 5-15 минут вылетает на 0,5 мс - и MSI прерывание или нет - ни как не влияет.
 
а вот драйвер отвечающий за работу выбранного Аудио девайса - в течении 5-15 минут вылетает на 0,5 мс - и MSI прерывание или нет - ни как не влияет.

А hdmi аудио устройств нет в компе? Вопрос, конечно, смешной, но вдруг чего) Не пробовали включать/выключать HPET в биосе?
 
Не знаю, но DPC это механизм присущий только Windows.
DPC - это термин винды, но плюс минус аналогичный механизм есть и в Мак ОСи, а как иначе может быть - для любых просчётов нужно время.
[DOUBLEPOST=1549751771][/DOUBLEPOST]
А hdmi аудио устройств нет в компе? Вопрос, конечно, смешной, но вдруг чего) Не пробовали включать/выключать HPET в биосе?
Системный звук конечно выключен, выход по HDMI звука есть на видео карте, и его я конечно тоже пробовал отключать...
Ситуация не меняется
 
Не знаю, но DPC это механизм присущий только Windows.

Я Вам по секрету скажу, что механизм отложенных обработок - это стандартный способ, используемый в том или ином виде во всех ОС. Ну эдак последние лет пятьдесят-шестьдесят, когда появились системы с разделением времени. Вот как раз пока не было разделения времени - вот тогда и не было еще нужды в этих механизмах. Но это времена зари электронных компьютеров тащемта например.
 
но плюс минус аналогичный механизм есть и в Мак ОСи
Я Вам по секрету скажу, что механизм отложенных обработок - это стандартный способ, используемый в том или ином виде во всех ОС.
Логично, что ВСЕ не RT системы имеют механизм разделения времени, но как в анекдоте "есть нюансы".
DPC я полагаю обладает большим быстродействием чем то что есть в других ОС, но за это приходится мирится с возможными проблемами.
 
@Oliver_Cray, мы это в ближайший месяц будем знать точно, так как пишем для нашего девайса драйвер Core Audio.
Mac OS на много более закрытая для пользователей операционка, но я уверен, что механизмы там схожие с Виндовс.
А то, что нет под Мак ОС такой утилиты как ЛатенсиМон, чтоб увидеть кто занимает буфер нужный нам для звукового потока - ну так нет, нужно просто сделать.
 

В общем, любые манипуляции с MSI дают плюс-минус одинаковый результат - тот или иной sys вылетает за 0,4 мс

Вот результаты при работе RME как ASIO (плэй проекта в Рипере):
после 1 минуты -
Сохраненное изображение 2019-2-10_9-47-8.446.jpg

Сохраненное изображение 2019-2-10_9-47-18.660.jpg

Сохраненное изображение 2019-2-10_9-47-28.426.jpg

А это через 10 минут -
Сохраненное изображение 2019-2-10_9-58-20.619.jpg
Сохраненное изображение 2019-2-10_9-58-32.281.jpg
Сохраненное изображение 2019-2-10_9-58-40.959.jpg
 
Тоже самое при использовании нашей Сетевой звук карты и её ASIO -
после 1 минуты -
Сохраненное изображение 2019-2-10_9-35-4.168.jpg
Сохраненное изображение 2019-2-10_9-34-40.47.jpg
Сохраненное изображение 2019-2-10_9-34-52.743.jpg

после 7 минут -
Сохраненное изображение 2019-2-10_9-43-18.126.jpg
Сохраненное изображение 2019-2-10_9-43-32.641.jpg
Сохраненное изображение 2019-2-10_9-43-44.284.jpg
 
  • Like
Реакции: itzh
Просто Ethernet драйверу отключил MSI режим (активна RME)
И ни как не связанные с сетью драйвера за 10 минут скаканули до тех-же преславутых 0,5 ms

PS: В общем комбинация какие из sys в MSI режиме, а какие нет, меняет только время возникновения DPC свышн 0,4 мс у неко орых их драйверов. Избежать этого я не могу.

PSS: Поставил 8.1 и DPC за час выше 0,09 мс ни на одном драйвере не поднимается....
И вот что делать?
 
Последнее редактирование:
Логично, что ВСЕ не RT системы имеют механизм разделения времени, но как в анекдоте "есть нюансы".

О да, нюансы есть ;) Например "механизм разделения времени" - это какой-то оксюморон. Есть "(операционные) системы разделения времени", именно они внутри подразумевают многозадачность/многопоточность и прочее. Я же говорю про отложенное выполнение, которое всегда есть в системах с многозадачностью/многопоточностью.

И вообще то, что называется Defer-чего-нибудь присутствует что в RT, что в не-RT операционных системах. Более того, средства, аналогичные DPC именно в RTOS используются наиболее часто в силу жестких приоритетов задач и необходимостью резко уменьшить время, потраченное на, скажем, обработку прерываний. "Все, что можно унести из потока с максимальным приоритетом в поток с низким - надо уносить" - это вообще такая концепция общепринятая.
 
@Aleksandr Oleynik, Это дает гарантированные задержки при обработке IRQ
Каким образом?
Вся загвоздка ж в планировщике задач, а он как крутился на ядре котрое осью занято так и крутится. Ну только если не вынести драйвера звуковые вкупе с отдельным планировщиком на "голое" ядро.
 
@Aleksandr Oleynik, @buncker,
MassCore contains what is truly the most powerful audio engine in the world. Able to process up to 384 discreet Inputs and Outputs (768 simultaneous), with latencies as low as 1.33ms, MassCore is also able to work at samplerates up to 384 kHz and DSD64/128/256.. For engineers who need the best, Ovation MassCore is the ultimate choice.
Я так понимаю MassCore не использует ASIO.
 
@Oliver_Cray, это Володин бы подробно мог рассказать.
Но, если честно, то я и с ASIO получаю задержку раундтрип меньше 1 ms.
Ну и MassCore только с продуктами Мерджинга может работать, а ASIO универсален.
 
Последнее редактирование:
  • Like
Реакции: itzh
@Aleksandr Oleynik, там видимо одно ядро "отчуждается" чтобы обслуживать только IRQ и драйвер своей железки.
Но как оно отчуждается из системы и при этом "обслуживает" "драйвер"?... - загадка.
Вне системы слово "драйвер" не имеет смысла.
Чёрная магия.
На самом деле было бы интересно узнать кто занимается расстановкой приоритетов IRQ, и можно ли повысить приоритет звуковухи. Это дало бы бОльшую гарантию стабильной работы в режиме IN-DAW-OUT. На DAW-OUT почти не повлияло бы.
 
там видимо одно ядро "отчуждается"
Емнип, не одно, а по выбору и только физические, НТ не поддерживается. Если я всё правильно понял, на этих ядрах там строится подобие DSP, на котором работает микшер и плагины собственного формата.
ЗЫ: цитата из статьи на Молайне
Принципиальное изменение произошло в 2007 году, с выпуском Pyramix версии 6, когда в компании Merging Technologies разработали программное аудиоядро под названием MassCore. Принцип его действия объясняется следующим образом. В компании считают, что современные центральные процессоры достаточно производительны для выполнения операций по подсчету данных, требуемых для многодорожечного аудио. Слабым звеном в данном случае является операционная система, располагающаяся между прикладной программой и процессором, и вызывающая задержку выполнения операций. Технология MassCore как бы прячет одно или несколько ядер многоядерного центрального процессора от операционной системы и напрямую использует их для нужд программы Pyramix. В современно исполнении это позволяет компьютеру с одним четырехядерным процессором поддерживать одновременно 384 входа и 384 выхода (при частотах дискретизации до 48 кГц) со временем ожидания 1,33 мс, 256 аудиошин и практически неограниченное количество плагинов.

http://www.moinf.info/articles/merging-technologies-pyramix
 

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