USB Clock Upgrade My Experiences (so far)

[PeterSt]

When I'm on my taking stand anyway ...

You guys may not know it, but the native 384Khz sample rate for USB exists because personal me created that. So it doesn't matter which literal interface exists (the one in the NOS1 is just one of them), but I did that. No matter Windows or Mac (and Linux I don't know about). Important ?

Well, only because I know how much things are at their limits and merely :

I forgot the exact situation, but either it is the too low buffer size (think Q1 x xQ1 x Device Buffer Size) or the KS Special Mode does not report any errors anywhere, while you can the most clearly hear the samples being skipped. So :

The Kernel Streaming core of Windows is a huge pile of code which is beyond the developer (it is even beyond Driver developers) and although with Asnychronous USB this is all error checked (also see the NOS1 Driver Control Panel), not all errors are reported by the OS which means all plays happily along but not with all the audio data.
This is not only at the more (driver) hardware level, but also on the side of the audio playback software like XXHighEnd (XXEngine3.exe to be literal). Thus, errors can be reported also in there (my software) but if they just are not, what do do (but play and hear gaps).

The above is about the extreme that so many samples are skipped that you can easily hear them. Think 1000s. However, at just dialling your Q1 higher and higher you will see that at some stage you can't be sure anymore; the last ticks disappeared but with the (my) knowlegde that this will be a couple of dozens; what when it were 3 or 1 ?
Notice : just testing it like this will I think show errors in the Driver Control Panel, so not so easy to comprehend).

I am certainly not claiming this happens actually all the time; what I do say though is that it can exist without the notice of errors being reported.

I can tell you one other nice thing :

Before this audio life I was into a video life; Well, if you dive into how the frame rate of video can plainly never match the sample rate of audio (the both just can not be divided into eachother) ... you know what the official means is to let the video not stutter ?
Just leave out audio samples.
(n.b.: In later stage smart asses like I think Ogy or something created ReClock and that was ahead of things by means of first adjusting the frame rate of video so audio would match that; movie may run a tad too fast or slow, but who notices that).

This is a formal thing, with that only saying that "something" is in there which can do this officially, and which just as well can be used to re-synchronize audio samples which can't keep up with something else. But the other way around. So if only our processor is not in time with serving those samples to be pushed through in time, they can officially be discarded. I mean, the code to do this is in there somewhere and don't you think that the particular Windows OS core code can be (or has been) reviewed by anyone still alive (so to speak) because it is as old as the way to Rome (we say). In the end this is about modular software which comprises of so many small pieces that nobody knows anymore what is performed when in which situation. But who cares, because it just works.

Yup.

Peter

[PeterSt]

Coen, accidentally I just gave you the answers I think. But notice :

The skipping has to happen before all is formally put out. So, whether on purpose like with the video example, or whether because of a bug - it is crucial that this happens before it goes out to USB because after that error checking will be in order and report.

Think software (you must be used to it like I am) :
Once it is known in advance that things are not 100% right because they just can not be (video example), it would be quite inconvenient to pop up a message that some samples were lost, right ? So first those samples are officially discarded and next what remains is as officially error checked.
Result ? no errors.
But also not quite right.

Peter

[PeterSt]

Someone must stop me ...

Remember - from about day one and Windows 8 I suggested skipped samples to clarify how the strange left/right behaviour could exist.
Notice that I mentioned this in this topic again, because it seems that phenomenon has disppeared and that I exactly know what I did to imply that (or hope it would). So this is Q5=1. However :

Whithout saying it much, I also know that it really would need something beyond me to keep it "stereo" to begin with. So, skipping bytes would break windows, and keeping together left and right samples would need something special. I mean, when at random (lack of time without it being under control) ONE sample is lost, meaning a sample of one of the channels ... that can't be and sure does not happen because it would imply a L/R change until it happens again.

So what is new for myself is thinking about the video example, which the most obviously would very decently skip TWO samples or an even amount (but also think multi channel).

Now, with the notice that there is a formal sructure for audio data that tells how many bytes (or how many samples) will form one logical audio sample (say for all of the channels in order and with the noitice that a sample rate of e.g. 768KHz is actually two samples of that for stereo so the rate is actually double that 768) ...
... it can only be a programmed thing to skip full samples (one logical for all the channels).

Don't ask me how decent core (kernel) drivers are to do this in a self-cointained fashion, but if so it is still part of the OS.
Thus, not a few bytes or anything are lost; no, always full logical samples are gotten rid of once only time is too short for even one byte. That's the idea now.
This means to myself that it is explained how things don't end up in a mess. It has to be a formal thing.

Hey, if in order at all of course !
Peter

[PeterSt]

Small brainstorm - may lead to nothing :

My PC runs at 750MHz. This is Hyperthreaded, thus 375MHz per core.
Audio playback runs in one core.

Thinking Redbook, 705600(sampling rate) x 2(ch) x 4(bytes) = 5,644,800 bytes need to be transferred per second.

375,000,000 / 5,644,800 = 66 cycles of the processor are available to do it all for each byte.
It is my fault that only 375,000,000 are available for it and thus also that only 66 cpu cycles are available per byte.

Uhm, that does not seem very much to me !
Let's say that I only need one line of C++ code to hand that one byte to the audio buffer (never mind what that is) and that it will not be wildly off to think that one of such a line takes 6 lines of machine code, then only 11 cycles (66/6) are left to process one line of machine code. Uh-oh.
These 11 cycles should include wait cycles for the various transfers from memory. Next, the remainder of the work is about switching buffers, activate them and some more overhead. I already don't see it working ...

On the other hand, when the "load" of the playback is related to the cpu usage (which shows maybe 2% for all the cores in total, but the one crucial core also showing "nothing"), then what to think of that ? That the percentage showed it not correct ? can be. Or that I make so huge mistakes in above math ? can also be but of course I don't see that.

Point is a bit : I know why and how I created Q5=1 and how that hugely avoids unnecessary processor cycles needed by the OS itself, and how exactly that makes the L/R thing and more strange sound go away (btw still working on that).
*If* this avoids missing samples (all of them ?) then I think that my 750MHz general processor frequency isn't all that much too low because normal speed would only be 4 times higher that implying 4 times less sample loss; it would be a total coincidence when that 3GHz suddenly could process all samples, plus that 5 years back it couldn't have existed.

Let's stick to my math being wrong for now; seems more safe.

[acg]

Hi Peter,

I've been trying to figure out how to make a good post about digital jitter and attenuation but I am having trouble getting things done on this iPad (am travelling).  Here is a link to an article instead.  

My key take home point is that the higher frequencies attenuate more easily and are more prone to jitter, which means that using a faster bus (eg. Sata 3 compared to sata 2) must run a higher frequency and is therefore more prone to jitter (but not the kind of jitter that is not totally eliminated before the dac).  How much extra noise is created by digital jitter through resends and the the like along with the size and frequencies of this noise are the pertinent questions.  Can this noise actually become audible?

Sorry for the lazy reply, but I have been trying to get this reply done for nearly an hour...damn iPad.

Anthony

[AlainGr]

Small brainstorm - may lead to nothing :

My PC runs at 750MHz. This is Hyperthreaded, thus 375MHz per core.
Audio playback runs in one core.

Thinking Redbook, 705600(sampling rate) x 2(ch) x 4(bytes) = 5,644,800 bytes need to be transferred per second.

375,000,000 / 5,644,800 = 66 cycles of the processor are available to do it all for each byte.
It is my fault that only 375,000,000 are available for it and thus also that only 66 cpu cycles are available per byte.

Uhm, that does not seem very much to me !
Let's say that I only need one line of C++ code to hand that one byte to the audio buffer (never mind what that is) and that it will not be wildly off to think that one of such a line takes 6 lines of machine code, then only 11 cycles (66/6) are left to process one line of machine code. Uh-oh.
These 11 cycles should include wait cycles for the various transfers from memory. Next, the remainder of the work is about switching buffers, activate them and some more overhead. I already don't see it working ...

On the other hand, when the "load" of the playback is related to the cpu usage (which shows maybe 2% for all the cores in total, but the one crucial core also showing "nothing"), then what to think of that ? That the percentage showed it not correct ? can be. Or that I make so huge mistakes in above math ? can also be but of course I don't see that.

Point is a bit : I know why and how I created Q5=1 and how that hugely avoids unnecessary processor cycles needed by the OS itself, and how exactly that makes the L/R thing and more strange sound go away (btw still working on that).
*If* this avoids missing samples (all of them ?) then I think that my 750MHz general processor frequency isn't all that much too low because normal speed would only be 4 times higher that implying 4 times less sample loss; it would be a total coincidence when that 3GHz suddenly could process all samples, plus that 5 years back it couldn't have existed.

Let's stick to my math being wrong for now; seems more safe.

Peter,

Have you done the same tests, this time with the CPU at its full speed ? And with the hyperthread off ?

Regards,

Alain

[PeterSt]

That the understanding of these sources of noise might help develop ideas on the underlying reasons behind the jitter. Could this be wait state related ?

Nick,

If you'd examine the Wait States you will see that when set ("configured") the most badly, there's a cheer over 100,000 per second CHANGES of that. Here are your hints :

Look at what each C1, C2, C3 indiviually does. This is important. Incorporate the cache sizes (for each).
Only BIOS changes (weird combinations of settings) may bring mentioned 100,000 of the worst kind back to 10,000 of the best kind, one of hem being totally dead now.

I don't require you or anyone to dive into these matters, already because you can't (or it can't be expected that you can). But do notice (or trust me) that mentioned 100,000 is about copying 256K or 2MB of memory that number of times per second. This is not bad in itself because the processor cycles are just used to cool the processor (that's what the Wait States are about). Hey, CRAZY ! The thing must be quite busy just cooling itself. Got it ?
In the mean time it creates noise (that assumed and that especially assumed to be harmful).

So Nick, while you bring this up as a mere side note subject which could be a larger subject, "we" are now (and we = XXHighEnd) right down at that level manipulating). Let's keep that a secret, okay ?
haha

But ... when something like a PCI bus, or memory state or USB or whatever so much more, was not ready for the next processor cycle, there we go again with wait states and stuff which will be forever beyond me. But we might be able to reverse-engineer it. At least that's what I'm trying to do.

Before we get confused - this now again is about the sheer noise issue and not about missing samples. But I am as far as thinking that it can be related. Look :

What I have running today is the above being worked out to some extreme. So, what I intend with it, works. However ...
While in W7 I can see that "something" totally stalls for which I can't find the reason but audio plays, on W8 that same thing does not stall, but it makes the USB interface being unable to recover from ... (re ?)transmission errors. Aha. Here too, I see no reason for it, but it happens. So say that all I do is driving things over the limit and now USB can not recover. Tell me what happens right under that limit ? I should be implying retransmissions without knowing it. But, just a guess. And you know with what parameter I am playing with and trying all of the others which all do not influence this ?

Well ?
The SFS.
(and oh, although I spent a full day debuging it by now, it will turn out that it is my own bug somewhere; but what puzzles me is that this doesn't happen with W7 while no code is different for the both, and that simply an SFS of 18 and higher will just crash W8 - in my sneaky situation as of now).

And what has been that foremost major key sound influencing parameter forever long as it exists ?
No answer needed.

So I do not see pieces of the puzzle coming together as of yet, but I do see more pieces of the puzzle, while all the pieces are needed to form the puzzle anyway.

To now briefly emphasize an important (or crucial) piece of that puzzle : Your both guy's heavenly trimmer on USB. It just totally prooves that one way or the other (noise which implies jitter or skipping samples) is in order. A 10 fold number of pieces are added for me, when similar can be done with a PCI frequency and such. I myself already had a bunch of pieces because again software itself can do it (didn't we agree ove that, no matter no mutual listening has taken place).

Can we be enthusiastic ?
I think we can.

Peter

[PeterSt]

Small brainstorm - may lead to nothing :

My PC runs at 750MHz. This is Hyperthreaded, thus 375MHz per core.
Audio playback runs in one core.

Thinking Redbook, 705600(sampling rate) x 2(ch) x 4(bytes) = 5,644,800 bytes need to be transferred per second.

375,000,000 / 5,644,800 = 66 cycles of the processor are available to do it all for each byte.
It is my fault that only 375,000,000 are available for it and thus also that only 66 cpu cycles are available per byte.

Uhm, that does not seem very much to me !
Let's say that I only need one line of C++ code to hand that one byte to the audio buffer (never mind what that is) and that it will not be wildly off to think that one of such a line takes 6 lines of machine code, then only 11 cycles (66/6) are left to process one line of machine code. Uh-oh.
These 11 cycles should include wait cycles for the various transfers from memory. Next, the remainder of the work is about switching buffers, activate them and some more overhead. I already don't see it working ...

On the other hand, when the "load" of the playback is related to the cpu usage (which shows maybe 2% for all the cores in total, but the one crucial core also showing "nothing"), then what to think of that ? That the percentage showed it not correct ? can be. Or that I make so huge mistakes in above math ? can also be but of course I don't see that.

Point is a bit : I know why and how I created Q5=1 and how that hugely avoids unnecessary processor cycles needed by the OS itself, and how exactly that makes the L/R thing and more strange sound go away (btw still working on that).
*If* this avoids missing samples (all of them ?) then I think that my 750MHz general processor frequency isn't all that much too low because normal speed would only be 4 times higher that implying 4 times less sample loss; it would be a total coincidence when that 3GHz suddenly could process all samples, plus that 5 years back it couldn't have existed.

Let's stick to my math being wrong for now; seems more safe.

Peter,

Have you done the same tests, this time with the CPU at its full speed ? And with the hyperthread off ?

Regards,

Alain

Alain, if I only knew which "tests" you are referring to. What must I test ? Nothing goes wrong you know (disgregard my last post of course). All I know is that the lower processor frequency brings me the best sound.

Regards,
Peter

[PeterSt]

Hi Peter,

I've been trying to figure out how to make a good post about digital jitter and attenuation but I am having trouble getting things done on this iPad (am travelling).  Here is a link to an article instead.  

My key take home point is that the higher frequencies attenuate more easily and are more prone to jitter, which means that using a faster bus (eg. Sata 3 compared to sata 2) must run a higher frequency and is therefore more prone to jitter (but not the kind of jitter that is not totally eliminated before the dac).  How much extra noise is created by digital jitter through resends and the the like along with the size and frequencies of this noise are the pertinent questions.  Can this noise actually become audible?

Sorry for the lazy reply, but I have been trying to get this reply done for nearly an hour...damn iPad.

Anthony

Hey Anthony, thank you for that effort;

It is a bit tough for me to decently reply to it, because it seems that you are on the right track with your perception of necessary recends (because of a higher transfer frequency ? <- I don't think so) while using an in my view unrelated article. All I can do is repeat my post about this, which doesn't seem much useful.

That article discusses jitter in a different fashion, because it compares the integrity of a signal (with itself) through an analyser which can be connected the wrong way. So, envsion the original signal (virtually on that scope) while it is compared with a degraded signal because of cable reflections and all mentioned there; It would show a false result only because of how the analyser is hooked up.
"Jitter" there is just used as delay, which in the end is a form of jitter.

Only when jitter gets that bad that not only the sample is captured too late (like for audio this will matter audibly) but that it is completely missed (crucial for your data send over the internet etc,), you can call jitter important up to devistating (but resends can recover the good signal assumed the errorneous receipt can be trapped); So this "digital jitter" (I'd like to call our audio phenomonen analog jitter) is quite crucial when very long distances are in order and it becomes easy miss complete "samples" because the jitter gets too bad.
Missed sample in THIS case : "Sampler" just reads signal, but signal is low again because too late while when it would have been in time it would have read a high (this is not 100% correct but gives the idea, especially emphasizing that such a thing NEVER will happen with audio <- haha  So, people often think that plain errors slip through and therefore wrong valued samples and such, but for audio it is not about that; only timing (when is this always good value put out up to the femto second). This not to be confused with my little subject of skipped samples because the OS thought it better cook an egg first.)

Peter

[Jud]

With the perception of asynchronous USB (which can be considered normal (and error checked) computer data) not being subject to jitter, it has been long time proven that at the DAC's end "noise induced jitter" is there for a fact (because we know of no other reasons which can influence in-DAC SQ), unless it is about data loss to begin with *before* it travels the USB interface. This is not likely but to be taken into consideration just because it is an option.

*  *  *
Open to any kind of response - or let's just continue the subject ...
Peter

I know you are excited about the data loss part of this, but please allow me to dwell for a minute on the other part, induced jitter.

What I have read from a number of people (going all the way back to Hawksford and Dunn, perhaps earlier) suggests jitter can be induced at the point where the DAC chip evaluates the "bits" and converts them to analog in at least two ways, by noise or by micro power supply fluctuations.  Would you consider any such power supply fluctuations to be lumped under the general heading of "noise"?

[PeterSt]

Hi Jud,

Yes, why not. And with the notice that both your (supply ?) noise and "fluctuations noise" are in the end the same (and notice my small twist of those words).
But with this given as a (well known) fact, it now is about how the various "outside" noise sources can travel that route, what those sources exactly are and how they can be to our benefit (assumed they can not be avoided anyway).

Regards,
Peter

[AlainGr]

Alain, if I only knew which "tests" you are referring to. What must I test ? Nothing goes wrong you know (disgregard my last post of course). All I know is that the lower processor frequency brings me the best sound.

Regards,
Peter

Sorry Peter, I was referring to the potential missing samples in relation with a slower CPU, but at least your answer tells me that you consider this unrelated...

I thought of this because I have read recently that some people do not sense FLAC files to sound much different from WAV since they changed their PC for more powerful ones...

Alain

[CoenP]

Not to forget that noise also can get in a dac chip circuit by EMI or RFI or can be correlated to the incoming signals (like on chip switching noise for the data line).

You can address a lot of this noise by design (also on the chipdesign itself), but vhf will remain hard to beat.

This noise either translates to imperfect timing (even if the input is perfect) or to physical noise on the outputs (which can be very HF) disturbing the analog stage.

Anyway it will be both the noise level and spectrum that matter. Both can be manipulated with software and hardware measures like grouding schemes etc. While Peter may focus on the software part lets not forget what allready has been archieved on the hardware level. Imho there is further potential in the two to explore.

Wrt to dropped data: it is allways dangerous to not know what you assume! For one thing results of the past are no guarantee for the future especially with an operting system that is not your own (hint  ).
Ultimately it would be interesting to know what data is offered to the driver and what data arrives at the dac chip. It should not be so hard to design (or buy?) a card that is able to capture the dac interface signals and store them as  music data in a file. Then software can be applied to analyse the correlation. If we find perfect correlation we can rule out the data drops and it will be a noise only problem.

Regards, Coen

[Nick]

I just dropped back into the thread whilst commuting on the train. I turn my back for a few hours and it's going to take a week to catch up  , really fascinating stuff !

Just one thought is anyone able to test the turning measures I mentioned in the post last night. Do other people get similar hardening smoothing and sweet spot sound from ram speed, bclk and cpu ratio settings. I know not many at the moment can play with usb clock speed but it would be good to know that the observations are repeatable.

Nick.

[Scroobius]

As mentioned last night Nick I cannot at this time because my PC will not boot unless I reset BIOS and load default BIOS values every time because my PC does not like the external clock running on the pcie card before it boots up or so it seems.

Very frustrating.

And wow there is some really interesting stuff here this seems to be a pandora's box with more in it than I could have imagined.

Paul