Касательно “реалтаймово”, “без джиттера” или как-то ещё - на мой взгляд наблюдается подмена понятий. Разумеется, описываемые “serializing instructions” сами по себе не приводят к некому сферическому jitterless в вакууме и уж тем более, - к real-time. Просто итоговый джиттер принято классифицировать как совокупность рандомного и детерминированного. В соответствии с приведенными результатами по функционированию генератора случайных чисел, рандомная составляющая существенно снижается, но как это скажется на итоговых задержках не ясно. Могут даже наоборот, увеличиться. При FFT-анализе вместо белого шума должны наблюдаться некие выбросы (patterns).
Изоляция процессов по ядрам по логике должна как раз должна нивелировать влияние “serializing instructions”, но на практике далеко не факт, что это будет иметь место. Даже в случае конфигурации с двумя многоядерными процессорами.
Полагаю, основная причина в out-of-order выполнении инструкций в современных CPU. Чтобы полностью исключить этот фактор, необходимо задействовать старые модели:
Most modern out-of-order CPUs are inherently out-of-order, without switching possible between in-order and out-of-order modes.
You can try to find some in-order CPU, and there are some:
x86: Intel Atom (only 45 nm and older versions; they have two parallel pipelines but executes all instructions in order)
arm: Cortex-A8, and many older cores;
While it is not possible to directly turn off instruction reordering in the typical out-of-order CPU, you can inject something serializing (like cpuid in x86 world) between every your instruction to simulate in-order execution.
Дабы не повторяться, конкретно данному вопросу посвящена ветка:
Коротко: реализация истинно асинхронного usb - редкая птица и в большинстве случаев реклок, как таковой, отсутствует. Но даже его наличие не спасает, влияние качества транспорта остаётся.
Вне зависимости от того, выполнена изоляция процессов или нет, любой модуль ядра имеет возможность выполняться на CPU, загруженном приоритетной задачей, ибо по факту у нас soft-realtime (тем более, под стоковой Windows, которой вдруг приспичило почесаться в другом месте). В идеале необходимо либо переходить на hard real-time OS, либо вообще на bare-metal реализацию по типу memtest86. Генератор случайных чисел пробовали запускать даже в таком режиме “без OS”, но это совсем экстремальный вариант.
Проблема ведь совсем не в пропущенных или битых пакетах… Если дело доходит до такого - впору кричать караул
Этот подход вполне в русле классических - “причесываем” OS (wtfplay тому пример), настраиваем CPU affinity и т.д. Можно вообще отказаться от многозадачной системы и перейти на стационарный твердотельный проигрыватель с 8-битным процессором 8051 серии с прошивкой на ассемблере. Никаких вопросов.
Дабы избежать двусмысленности - я не ТС и отнюдь не агитирую за применение каких-то утилит с непрозрачным алгоритмом работы. Мне просто любопытны возможные механизмы влияния и вполне допускаю, что могу ошибаться в своих оценках, поэтому сразу привожу варианты проверок. Пользоваться ими или нет - лично право каждого.
В отношении многострадальной Windows не раз слышал высказывание: “загнанных лошадей пристреливают”. Как видно, к этому готовы не все… Некоторые даже пытаются “оживить”, скажем так, не совсем традиционными методами.
Основная проблема компьютерного аудио в отсутствии четких критериев “timeperfect” и способов его верификации. “Bitperfect only” давно пройденный этап.
Подобное отсутствие четких объективных критериев - проблема не только компьютерного аудио и не только аудио. Проверка на различия для конкретного индивида в конкретной ситуации - пройденный этап, давно придуманы слепые тесты, с той же ABX методой например ))
Но большинству гораздо прикольнее запустив в соседнем с плеером окне в Windows особым аудиофильским способом покрашенное окошко Excel (например) и обливаясь слезой переслушать всю аудиотеку заново. Чем проверить а есть ли для тебя подтверждаемая разница - это муторно, требует усилий, а на выходе - только разочарование…
И, по-хорошему, методика тестирования AES предполагает множественные подходы к снаряду и не одного испытуемого. На выходе получаем тестирование самого эксперта на предмет распознавания явных отличий.
Тестирование на длинной дистанции, как правило, выполняется куда проще, но менее эффектно.
А про отсутствие реклока в большинстве случаев откуда вывод взялся? Судя по всему всему ровно наоборот - маркетинговый термин “асинхронный USB” означает именно наличие реклока, а не что-то иное.
Из шкурного интереса сделать для себя выводы, провел инвентаризацию на примере домашнего зоопарка ЦАПов с USB:
1, 2 Chord Hugo TT и Chord QBD76 HDSD - производитель и asynchronous USB и реклок заявляет
3, 4 Lynx Hilo и Mytek 192 - видимо в проф мире “asynchronous USB” менее имеющий хождение термин, про синхронизацию на внутренний клок при этом оба производителя заявляют
5 Matrix X-Sabre Pro - и asynchronous USB и реклок заявляются
6 Audiolab M-DAC - наиболее туманный пассажир, asynchronous USB с буфером заявлен, а вот про реклок явно не нашел в мануале. Только косвенные заявления от разработчика на pinkfishmedia в духе например - внешний клок не нужен, т.к. асинхронный USB клочит.
Из 6 ЦАПов 5 явный реклок, 1 под вопросом, но тоже скорее да. Так что резюмировал бы вывод обратный - в случае декларации производителем асинхронного USB (или в проф устройстве средней руки с USB) вы вероятнее всего будете иметь клок от ЦАПа…
У меня было по 3 подхода вечером и утром следующего дня.
Как в предыдущей ветке писал так и тут повторю - мне интересно для себя прежде всего сделать выводы ) Если я сам не слышу разницы, что мне с того, что кто-то другой более чуткий маркеры научился для вылавливания различий выявлять. Для меня вывод прежний - разницы я объективно не слышу (про субъективную часть в ветке по bitperfect написал).
И если бы хоть кто-то кроме меня про результаты слепого теста написал - уже был бы шаг от выводов одного эксперта к выводам для определенного человеческого сообщества. Про результаты тестирований очных в целом, повторяться смысла нет. Разве что в контексте конкретного кейса можно похихикать )
Кстати, MinorityClean 96 скачал, разницы не услышал.
Отдельно добавлю, что на bitperfect-ность софтина (даже с приоритетов reealtime), к счастью не повлияла. В отличие например от совета буфер ASIO до нуля уменьшить, что в моем случае к срыву теста bitperfect приводило. Так что как вывод (для себя) - относительно безобидная, как и бессмысленная штука. Но читателям советовал бы быть внимательнее с экспериментами, судя по тому что выше писалась - в каких-то случая применения можно и о кривой передачи музыкальной информации доиграться (если есть потенциал даже железо повредить). Не забывать выключать после поигрушек подобные штуки.
В свое время Шарапов устраивал мне двойное слепое тестирование в незнакомом (мне) тракте и на незнакомом материале. С горем пополам прошёл, но лично для себя подобные “перетыкивания” делать зарёкся.
При любом раскладе мы получим частный кейс - в Австралии живет не менее одной овцы, и она черная, как минимум с одной стороны.
Методику объективного теста привёл, как будет время - сделаю, самому интересно.
Matrix X-Sabre Pro, на мой взгляд, под вопросом, т.к. “асинхронность” в данном случае скорее всего относится к примененному ESS9018. Пруф отсутствует. По остальным не смотрел.
Уж не знаю где вы пруфы смотрели, но учитывая, что в этом ЦАПе 9038, а не 9018 - явно где-то не там и не про то) Судя по всему синхронно 9038 используется, а асинхронно отдельные crystek.
Спутал со старой ревизией, не суть.
При sync mode цап должен ловить мастерклок от источника, при async - собственный мастерклок. При прочих равных предпочту сомневаться.
Про синхронное кривовато кальку с сайта взял, синхронно 9038 берет клок источника (X-SABRE Pro has the clock configuration circuit unit, can choose to use ES9038PRO synchronous clock source). Про async в чем сомнения?
Исходное сомнение было про применение реклока ЦАПом как синонима асихронного режима. В этом сомнения разве остались применительно к данному ЦАП и если да - почему?
(Про реализацию отдельно можно обсудить, если есть смысл. Исходно было положение, что в ЦАП клок будет лучше, чем в рандомном USB и для дальнейшего улучшения можно улучшать ЦАП. Даже если здесь задействована 9038, в чем противоречие тезису? Ну и тем более, раз декларируется использование Crystek?)
По той простой причине, что в данном режиме указанная характеристика относится к микросхеме 9038, а не плате приемника. Допускаю, что могу ошибаться, но, к примеру, для изделий W4S на тех же чипах дело обстоит именно так. В итоге шильдик “асинхронный” распространяется на всю совокупность узлов изделия.
В этой ветке уже пошёл сильный оффтоп. Пора закругляться.
