WatchDog:
southpaw, зачем мне лазить по этим помойкам? Ты своими словами расскажи. Или все закончится простыми необоснованными утверждениями? Как с теми золотыми настройками биоса и линейными БП для питания бешено шумящих импульсных стабилизаторов процессора...
Своими словами асинхронный интерфейс в цап, это не полное решение проблемы борьбы с джиттером, так как на практике при использовании такого цапа хорошо слышны аппаратные манипуляции с транспортом, ОС, плеерами, и кабелями.
Если тактирование USB контроллера в цап, происходит от генераторов цап через гальваноразвязку, а сам USB контроллер ЦАП имеет общую массу с хостом, или что ещё хуже питается от ПК, то о 50 ps можно забыть. Замена "ревущего" EMI ATX БП, на малошумящий, сильно улучшает ситуацию с синфазными помехами по линии USB. Далее удаление гальваноразвязки в цап, сильно улучшает работу контроллера USB, что слышно ушами даже тем, кому на них наступил слон.
Асинхронный ресемплер в самой МС ЦАП, что как правило и делается в большинстве реализаций в дефолтном включении МС ЦАП, лучше не использовать, так как в синхронном режиме с контроллером USB, звук намного лучше.
https://askentire.net/q/propusknaya-sposobnost-petli-fapch-vremya ... 1587818884
https://www.intel.com/content/www/us/en/programmable/support/supp ... itter.html
Beyond these sources, termination dependency, cross talk, reflection, proximity effects, VCC sag, ground bounce, and electromagnetic interference (EMI) from nearby devices and equipment can also increase the amount of jitter in a device.
Reflection and cross-talk frequency-dependent effects may be amplified if an adjacent signal is synchronous and in phase. Aside from noise caused by power supplies and ground, changes in circuit impedance are responsible for most of the jitter in data transmission circuits.
Индуцированный софтом джиттер:
https://books.google.ru/books?id=8aWiDQAAQBAJ&pg=PP45&lpg=PP45&dq ... er&f=false
https://jacr.avestia.com/2014/003.html
"бешено шумящих импульсных стабилизаторов процессора..." шум которых уменьшается в несколько раз при уменьшении тактовой частоты работы процессора со штатной величины до минимально возможной, из-за уменьшения в несколько раз потребляемого тока процессором, с соответственно уменьшением EMI и наведённого джиттера. В чём тут противоречие?
Линейный БП в данном случае выступает в качестве фильтра синфазных помех между девайсами.
https://www.psaudio.com/pauls-posts/software-jitter/
Certainly we recognize EMI and power supply spikes as a contributor to the SQ and have always paid close attention to the isolation and careful bypassing of these devices to keep power supply interaction low. But while what I am referring to is certainly related it is also somewhat unique at least in our experience.
EMI (RF) is a common problem all engineers have to worry about and we always have but it is the correlated nature of the RF as well as the power supply modulation that is unique in my experience. Any correlation between the audio signal and the power supply modulations or any RF interference sounds bad – and we now have the situation where the software program itself is responsible for the correlation between the program material and the CPU activities.
Our ears hear correlated interference as tonal changes and mostly ignore uncorrelated “noiseâ€.
As you no doubt know, anything that modulates the power supply can cause jitter. One example of the significance of that power supply modulation is that itâ€s possible to use power supply variances to attack RSA public key encryption by statistically detecting the different loads caused by having ones vs. zeros in a single multiply at a given point in time. The mere fact that this is being done again points to the correlated nature between the software and the power supply issues which is what we’re referring to as software jitter.
There are other ways for code changes in a CPU to manifest themselves besides jitter. E.g. via RF. CPU generated RF can enter via direct connection or via any RF antennae formed by loops. RF detectors can be any non-linearities in any component in the downstream signal path. (The most extreme example of this is the crystal radio.)
One should be wary of using diodes to do level clamping on an analog signal, but there are plenty of other non-linearities in the audio signal path: Even the DAC itself is obviously a non-linear device. (Another example is that we’re always wary of “non-polar-electrolytics†as well. The back to back caps are essentially two weak diodes.)
So indeed we’re dealing with supply modulations that upsets the temporal references of the digital audio chain inducing jitter as well as RF problems causing other types of distortion – and good housekeeping rules would always force us to pay close attention to isolation, lots of bypass caps, local supplies, etc. But the correlated nature of the device modulating the supply and generating the RF is specific to the software running – so my point is that we need to pay close attention to all – hardware, power supplies and the software itself in an effort to minimize MIPS.
I think the term software jitter seems appropriate since no matter how careful we are – different software will always cause different SQ.
) использует FLAC кодировщик и утверждает, что получает каждый раз разное качество звука, то он просто дилетант. И это легко доказать. Математика - тут всё чётко. 
звуком. Сделанных специально для таких как Вы.
