USB processor clock has impact on audio, tested on four different usb boards.
It is only 1.5-3 USD to try, perhaps later some members will confirm my experience. Huge improvement I've recieved on SA9227 usb receiver with independent 45/49 clocks with ES9039q2m in ASYNC mode without MCLK, with swapping 12Mhz processor crystal to cheap normal oscillator. Near the same was on another XMOS boards. This thing don't need and perhaps can't to be measured, it need to listen.
It is only 1.5-3 USD to try, perhaps later some members will confirm my experience. Huge improvement I've recieved on SA9227 usb receiver with independent 45/49 clocks with ES9039q2m in ASYNC mode without MCLK, with swapping 12Mhz processor crystal to cheap normal oscillator. Near the same was on another XMOS boards. This thing don't need and perhaps can't to be measured, it need to listen.
Sorry, but USB clock has no impact on audio when UAC2 interface is bit perfect to 32 bits. If it isn't bit perfect then there is something seriously wrong and swapping clock is not likely to help. Claims from listening when no proper controls are used and AB is not even possible are as convincing as fairy tales.
If the USB clock is causing some real audible effect, then it would almost certainly be due to analog noise side-effects and not because of bit errors. A well-designed isolator/reclocker system would hopefully take care of any poorly defined analog USB subsystem noise problems more effectively than a poorly defined reduction in USB clock jitter related noise.
This was about USB clock jitter, not USB clock noise (actually that 26MHz crystal is a reference clock, not USB clock). How would jitter in this reference clock cause audible analog noise side-effects (whatever that means)?
Don't know offhand. I would have to see one change the sound before I would start chasing around trying to figure how it was doing it.
the problem should be that too many ESS chips are using its own local clock but not the MCLK supplied by usb board? as only MCLK should matter in any conventional architecture..
That's true to a first approximation, at least. IOW, it is a model of a physical system's intended behavior. Maybe the actual physical system is a little bit more complex than the model being used?
Reason I have some doubts about the simple model is because once I did an experiment with an ESS dac where I moved I2S signals in 200ps steps relative to MCLK. IMHO there was a very slight sweet spot at one timing step, but it was really slight. I had to test myself many times before deciding it was real. I later did a similar experiment with AK4499EQ where MCLK series damping resistance was adjusted to affect MCLK timing relative to I2S bus timing. A friend could hear an exact spot to within 5-ohms of damping resistance where he said there was a peak in soundstage depth information. I couldn't hear it myself at the time, so I tried to fool him multiple times by making him find the spot again. I didn't know if it was the same spot or not while we were doing the listening test. Only after he said it was the right spot and we stopped was when I measured the adjustment pot resistance. Each time it came to within the same 5-ohm spot. Total resistance was well over the theoretical 33-ohms most commonly used. It was closer to 100R or slightly more. Anyway, yeah, these were not strictly controlled DBT, but it was enough casual evidence to make me wonder if the system model of nothing but MCLK alone being able to effect sound might not be a little bit oversimplified.
Of course, the above is a very different question than the one we started with. It had to do with a non-audio clock in the USB board circuitry. That's something I never thought worth looking at, but who knows maybe there could be some unexpected side-effect. I'm still not going to bother with looking at it so long as I am doing what I feel is reasonably good reclocking.
Last edited:
That is not a problem as such but often dictated by the DAC chip. Older ESS DAC chips (as the one used in Audiolab Q DAC) only support asynchronous mode (ASRC) so there is no need (or benefit) to use audio clocks as MCK. Synchronous mode came in later ESS DACs but in recent chips (Hyperstream IV) even ASRC works very well and is easier to implement than synchronous mode. Another reason for using ASRC is the jitter reduction for SPDIF.
I don't know what we need to measure, but here are one 5sec frame SPL&phase analysis identical wav recordings imported in REW from USB board CT7601 without audio clocks with crystal and XO. It is hard and nearly impossible to record the difference in sound stage with my cheap old ADC board WM8782, after recording it sound like this ADC, but even here we see a difference.
It is so easy to try and listen instead of theoretical discussion.
It is so easy to try and listen instead of theoretical discussion.
Attachments
If you are talking about clocking XMOS itself, it is not important.
It just has to comply with USB standards.
(100ppm, if I remember correctly, reasonable jitter is not important at all).
For all modern DACs, only MCLK jitter is important.
For ancient ones - WCLK and (sometimes) BCLK. SN74LVC74 solves this problem 100%.
Thus, if MCLK is provided by an external oscillator, there is no need to pay attention to the CPU oscillator.
Alex.
If that CT7601 board has only a 12MHz crystal it means that CT7601 generates audio clocks from that which is a very bad solution with high jitter. In that case quality of the 12MHz clock may have an impact but it hardly matters as the result is bad anyhow.
But all this is irrelevant to this thread as Audiolab Q DAC has a separate MCK for audio.
It is still a very bad solution as the generated I2S signals have high jitter and a frequency error as well.
If you post measurements you should at least describe what is being measured and how. SPL is not a proper vertical scale for such measurement.
If you post measurements you should at least describe what is being measured and how. SPL is not a proper vertical scale for such measurement.
Decide already, sometimes no impact, sometimes it gives high jitter on I2S output.
Perhaps we don't understand each other, I'am talking about clock of any USB processor which makes I2S for our DAC. It has impact, but I don't know how to measure it.
Yes and yes.
It gives high jitter in I2S, but who cares?
There is no impact of this jitter to audio signal.
No, there is no impact in most cases.
No impact if USB processor's I2S port clocked by external oscillator (MCLK) and have impact, is MCLK is generated by CPU PLL clock system.
It was explained many times, I don't want to repeat.
Alex.
Well, I'll have to order another one USB board with CT7601 and left it with xtal and then it will be easier to swap them and record and record again and to search what I hear. It is about sound stage, it would not seen at standart tone measurements. Perhaps need to try Delta Wave
BTW, I've record SMSL DAC before changing xtal on XMOS and after, and after inverting and playing two WAVs together there is airy high frequency sounds, but not silence. Will work in this direction.
BTW, I've record SMSL DAC before changing xtal on XMOS and after, and after inverting and playing two WAVs together there is airy high frequency sounds, but not silence. Will work in this direction.
Last edited:
You are confused as these are totally different devices. As I said the 26MHz clock on XMOS in Audiolab Q-DAC has no impact on audio as it has nothing to do with audio signals. But your CT7601 is a totally different design which uses a 12MHz clock to generate audio signals. ASRC on ESS dac can suppress most of the jitter from CT7601 but on other DACs the high jitter of I2S may be audible.
One way to assess the impact of CT7601 crystal is to record 11025Hz -3dBFS at 44100kHz sample rate with e.g. 1M FFT 8 averages using Blackman-Harris 7.
But as this has nothing to do with this thread I suggest you create a new thread.
But XMOS uses this 26Mhz xtal as main clock for itself and also in the end in order to generate audio signal, does not it ?