I think it generally works fine, and is used in a lot of products, but makes the jitter-obsessed twitch because the clock must be recovered from the data - similar to SPDIF.
Yes - the most noise is definitely where the mains leads emerge from the transformer - but I have noticed it is not uniform at other positions around the core. On most of the wound transformers I have seen (and used) there is inevitable bunching of the windings - no big deal when you look at it or when its taped up, but the mag fields are a bit bumpy as a result.
I might make a change one day, usually to my or speakers position/directivity these days, that's where it's at (incase you didn't already know
) Then, if a few days down the line I find myself casually listening to a familiar recording for pleasure only and noticing something I haven't heard before, I take it as a good sign, and progress.......Of course, we could always argue that with propper implementation in the end device everything before (if not leading to real missing data) shouldn´t have any impact - large buffers for maximal decoupling of incoming and outgoing data streams for example.
But i just tried to follow the line of reasoning to show that is usually depends on the models the people (who are actually designing the devices, and others who are judging about audible effects) are using.
Models normally represent simplified versions of the reality and therefore we need to examine if predictions from the models are correct.
Jackob: agreed. Even if (for me) the only audible effect from sync operation is that my music stutters when windows starts thrashing away as it is wont to do.
On my linux server I hear no issues, just music. But I may be insensitive to the issue due to my not expecting there to be an issue. Prejudice works both ways!
On my linux server I hear no issues, just music. But I may be insensitive to the issue due to my not expecting there to be an issue. Prejudice works both ways!
That delay or stream interruption is probably not related to the type of UAC endpoint - just a buffer underrun that would occur with asynchronous operation also. Linux is better at this because ill-behaved 3rd party drivers that aren’t part of the kernel tree are much less common.
Typically it’s just a poorly written driver. Even Linux doesn’t have a fully preemptable kernel in a normal configuration.
One of the worst Windows audio drivers I’ve seen is the Focusrite 2i2 driver. I’m not sure who they paid for that, but they should get their money back. I think it’s one of the companies selling XMOS / UAC drivers, but not Thesycon.
Last edited:
Right, the only device that completely stopped working as simultaneous play/record with a routine update, though I have to admit the QA400 was totally bricked by the last update.
You can’t.
Either DSD is fragile to power eunning through the cable, or the “audiophile” cable helps introduce RF and stray fields. I read about how a guy was astonished that where he placed his USB cable (audiophile) made a difference in sound, especially the orientation of the little box at the end.
http://www.hit.bme.hu/~papay/edu/Acrobat/Fund.pdf shows that -90dB IMD is created by 35nS jitter with a 997Hz fundamental (further details are in the AP white paper). The same white paper shows measurements of IMD/THD vs. jitter frequency. Once again, for a 35nS jitter, the maximum IMD/THD is reached for a jittered input signal of 20KHz and a jitter frequency of 5KHz, and is slightly over -60dB.
You seem to infer that as long as such effects exists, it is worth considering them. Not in my book; anything that belongs to the pathology of particular implementation(s) is of theoretical interest only. I am not in particular interested if such pathological implementation effects are audible or not.
A few years ago I measured the IMD products of a computer $10 DVD drive and the motherboard integrated DAC (don't remember the brand, but it certainly was nowhere near a top performer, likely a $2 chip). The total IMD products were around -90dB for a 3KHz FS reference input signal, and the distribution was bimodal (excluding therefore any major noise contribution, I have somewhere in my stack of paper further details, I can dig them if somebody is interested). I don't know how much was the analog chain contribution to this distortion level, but to me this pretty much closes any practical discussion about jitter effects. You may want to further theoretically quibble about, but I don't think it's possible to invoke e.g. any USB cable audibility reports (or justify a need for exotic parts) on this basis.
Last edited:
hitsware;5703458 What I mean is you can actually use (power) toroids as output xfmrs as opposed to (power) E-I's and pass a semblance of a square-wave .[/QUOTE said:hitsware, thanks for the clarification .
I am aware that power toroidal transformers are good as audio transformers (and much worse as 50Hz psu transformers
At least you don’t get random blue screens from it. That’s what happens to me. I looked at the kernel dump and LatencyMon output to make sure it wasn’t something else causing the bad behavior.
It also doesn’t present itself as a normal input device depending on the API the application is using. I haven’t hunted down which or why but Skype for Business and a couple other apps actually fail to see it as a valid audio input device despite showing up in Control Panel just fine.
Meanwhile the EMU drivers stopped being updated before Windows 8 existed and still work faultlessly with very low latency. Patchmix was quirky but it was robust for me.
Have you questioned those who posted audible difference claims by using casual subjective comparison such as "In my experience USB cables can/do cause 'signature'"?
If you really were a sound engineer, then you would know how to interpret audio measurements which are published all over the internet. You only need to know a few DBT results to be able to correlate the measurements to figure out how DAC, preamp, amp and cables will sound like.
If you don't want to rely on objective test results, you are free not to.
- Status
- Not open for further replies.