USB Clock Upgrade My Experiences (so far)

[PeterSt]

Something else : I find it quite confusing that this is now in this "noise" topic while the "trimming" tells it should be in that other one about *that*. So I think I will move this ...

[Edit : Which I just did, see the  "A consistent approach to PC / DAC tuning ?" posts.]

Regards,
Peter

[Nick]

Something else : I find it quite confusing that this is now in this "noise" topic while the "trimming" tells it should be in that other one about *that*. So I think I will move this ...

Regards,
Peter

Peter hi,

For me trimming is not really the point of the post.

The underlying points are:

 Highlighting that jitter may be produced as data is sent across pc subsystem interfaces.

That the effect of conditions at these interfaces have consistent effects on sound and,

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 ?




The effect of tuning on sound quality is not so much of interest as it is what the observations might highlight about digital noise. Im sort of excited as the pc hardware has always appeared like a black box and here may be something that links cause and effect with  consistency, something that shows logic at  last.

The effects need to be further tested but the interesting conversation for me is what is happening to impact noise.

Cheers,
Nick

[PeterSt]

Nick,

When you talked about jitter in your previous post, some neck hairs got upright here. So the answer to that is No, I don't think that this can be involved.
But I had another kind of response in mind which does not suite this topic anyway. The other one yes.

Peter

[Nick]

Peter,

What are the options if not jitter induced changes in sound ?

So far back into the pc im not thinking this could be about analogue domain noise. Also a consistent effect from a similar situation in 4 different locations in the data chain and the sound characteristics sound like jitter spectrum.

The only other thing that springs to mind is that could have an effect like this would be data loss. But could this ? Seems unlikley.

So why the hairs rising at the mention of jitter ?

Nick

Edit actually when I say jitter im lumping in the idea of "lateness" of data moving through the sub systems. This could be different to jitter in a continuous stream I guss, a time related effect though. Actually maybe this is more likely.

Then there could be something that happens at an interface that effects other cpu processing. I guess this could be other stuff rather than jitter.

Anyway by all means move the post but im really not seeing how this fits with "usb clock experiences" if that is the post you had in mind. That post considers the effect of a single link in the chain whereas the discussion here should try to address a fat broader scope. In time I hope that with more experiment here the transfer from hdds can also be included or excluded in the scope of this discussion.


 

[acg]

Digital jitter within the computer is a well known and understood phenomenon that is overcome with buffers and asynchronous protocols, but I am sure both you guys understand it.  I read an article a while back regarding design of sata cables to minimise jitter which was very interesting but long story short I don't think this jitter can directly impact the NOS1 which is the thought that may have raised Peters hackles.  Indirectly though, maybe there is some influence of the extra noise generated by the asynchronous digital resends with the computer that we are able to hear on a dac such as the nos1.  Maybe.

Anthony

[acg]

Hi,

This is a post that i’m really pleased to be making, there is a very nice gain in sound quality but I'v had a feeling that there should be a more consistent approach available to tuning the PC and NOS than I could find before.

What is here is the coming together of work on clocks, messings with BIOS settings and some help from the NEC USB chip datasheet the George posted a few days ago.

Lets start off with some sound quality characteristics that come about when tuning USB link clocks using the dexa "heavenly trimmer" haha (first touched on here  http://www.phasure.com/index.php?topic=2784.msg29143#msg29143)




So as the dexa usb clock speed at the PCIe USB card is tuned there are three sound quality conditions that occur:

1)   Sound characteristic 1 is super smooth, it sounds right and very appealing but when listened to you realise that dynamics / transients / weight / scale / and presence have suffered BUT the hardness in 2) has gone which is good.

2)   Sound characteristic 2 has a harsh element in the upper frequencies too much sibilance and on very complex passages particularly with lot of high frequency energy it feels loud in a poor sense.

3)   The “sweet spot”, sound characteristic 3 has smoothness and detail with good portrayal of dynamics / transients / weight / scale / and presence in addition there is detail but without the sibilance and harshness of case 2.
As you tune the dexa clock trimmer the tipping point to move from sound 1) to 2) via 3) (the sweet spot) is very rapid and takes a little work to find where sound 3 is to be found.




So far so good, some folks might recognise the sound types described. I have posted before on the CPU BIOS clock ratio setting and memory speed needing to be carefully set, on thinking these experiences and the dexa trimming about I was starting to see similarities in the sound types produced.

Then whist reading the NEC Data sheet that kindly George provided it was clear that data is being clocked in to the NEC chip from the PCIe bus which nominally runs at 100Mhz, hummmmm.....

So thoughts moved on, what if the main music data transition points can be tuned going backwards up the data stream from the NOS1 all the way back to the HDD, AND what if they behave in a similar way ? Now THAT would be something to work with ! -  a common principle that might be applicable to much of the PC and the USB link into the NOS.





So possible tuning points working back from the NOS upstream to the PC:

a)   PCIe USB clocl speed => NOS USB usb clock speed (using dexa clock trimmer on the PCIe USB card)

b)   PCIe bus speed => PCIe USB card clock speed (set using BIOS BCLK setting)

c)   CPU speed => PCIe bus speed (set using BIOS CPU ratio, (need an Extream mode lntel CPU for this) )

d)   RAM => CPU Speed (using BIOS Ram Speed setting)

So when tried the interesting thing is that each of the above four tuning points have exactly the same effect on sound. When the upstream side of the data transition is fast I get sound chrateristic no 1 when it is slow I get sound characteristic no 2 and then there is a knife edge transition setting which produces the sweet spot 3 in each case !

As an example a change in BIOS BCLK setting of less than 1% hops over the sweet spot setting from sound no 1 to sound no 2. In reality BCLK of 100mhz in BIOS = sound characteristic no 2 and Bios setting of 99.5mhz = sound characteristic no 3, the sweet spot, BCLK of 99mhz gives sound no2.

So I have spent  the afternoon messing about (being suppressed at the similarity of the effect of tuning each parameter) working from tuning points a) to d) above. At the end of this process sound is really excellent, better than I have heard before, silky smooth with ultra detail, coherent and with presence and scale tone and authority.

By a happy coincidence, last night I went to a carol concert at our town's cathedral to hear my daughter sing in a choir. It was a really nice evening but it also meant that I was listening to live church organ last night. Today with the tuning above the sound of reproduced church organ is very very close indeed to what I was hearing last night.





Settings on an ASRock z79 Extreme 4m mobo ended up as follows.

CPU BCLK = 99.5mhz
CPU ratio = 29
RAM 2100 Mhz
Dexa clock at the PCIe USB card 1/16th turn (about) clockwise from standard position (note running against a dexa set to standard trim position at the NOS USB interface.

Final thoughts.

I am strongly suspecting that the above may have something to do with any “wait state” that data encounters as it goes from one PC sub system to the next introducing jitter somehow. I'm also very excited about this, its the first time for me that a consistent approach applied to multiple points where speed can be tuned has resulted in totally consistent effects on sound quality.

Now I’m considering accelerating a project I have started to put a tuneable clock on a HDD, I know what I think it may do when tuned - but will it !! 

Best,

Nick.

Very interesting post Nick.  I will digest it I'm the coming days.  In the meantime you could probably consider playing with a low noise CF-sata adapter and a clock upgrade for it for the os drive in your XXHE pc rather than a HDD.  Cheaper and most likely lower noise than a HDD or SSD.

Cheers,

Anthony

[PeterSt]

Nick, consider me a little disappointed here. I thought at least I was on some track regarding how jitter can or will be noise induced and which is not the way you propose it. Am disappointed because it seems (or comes across as) you never read it. And yes, this is all in that other one topic (if my memory serves me well).
Odd.

Peter

PS: Maybe dive into asynchronous USB and how it is theoretically impossible to have that carry jitter. If you know about this, please support your claims by the reasoning how it in your view happens (no penalties when you are not correct, today or in infinite future). But just claiming it ? sorry.
What I don't get is that I spent maybe 10 posts about it and it seems you have missed them all ?

PPS: Apologies in advance for this not coming across as the most nice. I guess I am too floored to let it go.

[Nick]

Nick, consider me a little disappointed here. I thought at least I was on some track regarding how jitter can or will be noise induced and which is not the way you propose it. Am disappointed because it seems (or comes across as) you never read it. And yes, this is all in that other one topic (if my memory serves me well).
Odd.

Peter

PS: Maybe dive into asynchronous USB and how it is theoretically impossible to have that carry jitter. If you know about this, please support your claims by the reasoning how it in your view happens (no penalties when you are not correct, today or in infinite future). But just claiming it ? sorry.
What I don't get is that I spent maybe 10 posts about it and it seems you have missed them all ?

PPS: Apologies in advance for this not coming across as the most nice. I guess I am too floored to let it go.

Peter,

No problems, I'm trying hard to make sense of this myself. Perhaps you could point me at the points in the other post which will help me understanding your thoughts.

Having thought about this overnight regardless of theory there is something happening at the boundaries that changes perceived sound characteristics  and the effect sounds at least similar to jitter but again thinking overnight about this I think the I should not jump to any conclusions here.

As mentioned above could this be data loss ? Seems unlikely.  Or perhaps a transmission pause at an asynchronous boundary causes the cpu to go and do something else and this effects other processes I dont know, or something else....

What there is to work from is that there are consistent timing related sound changes where asynchronous transfers are taking place as Anthony pointed out. Beyond that I can't really go far with experiment other than to practically  test to see if the principle holds for other transfers like from the hdd.  I wonder if testing software to test the effect might be possible / interesting, i dont know.

I was reflecting last night that i had come across  the cpu ratio and ram speed effects before but its the usb clock work and putting this together with the pcie 100mhz transfer speed that allows the effect to be heard consistently and hints at a general principle at play at asynchronous boundaries.   

If you can point me in the direction of your thoughts I would like to take a look.

Regards,

Nick.

[PeterSt]

Ok, I merged the two topics. Reason :

The one we are looking at right now is about "trimming" or at least it rapidly received that subject; two topics explicitly about that is too confusing while it also it too important to have it all right and together (my view but alas).

If it is not clear what this should be about at this moment :

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.

That the latter is suggested to become more likely by myself through a number of posts in this topic can be considered "conspiracy thinking", but until proven otherwise - and with the notice that I don't know how to do *that* - it is and remains an option.

In the mean time and now NOT considering data loss, it will be noise travelling the USB interface that implies jitter at the DAC side, and when this is assumed to be the case, it is easily proven that when influencing the noise, the jitter will be influenced along with it.

It is also easy to see that influencing the noise can be done by means of at least two sources generating that noise, the both working into eachother creating a far bigger resonance (oscillation) with slower or faster repeating patterns than any single source could do in the first place (because no resonance possible).

All with the notice that for each and every source thinkable, all comes togetger in that USB interface (possibly any interface for that matter), with the confusing factor of the interface itself contributing to the effect because of its two oscillators at each end of the interface.

I can continue, but will not do this in this "recap" post because it will be speculation. What I said above is merely coming from logic though with the notice it is still mine which is no guarantee it is true.

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

[Nick]

Something else : I find it quite confusing that this is now in this "noise" topic while the "trimming" tells it should be in that other one about *that*. So I think I will move this ...

[Edit : Which I just did, see the  "A consistent approach to PC / DAC tuning ?" posts.]

Regards,
Peter

Peter,

I think with the merging with this thread the "consistent tuning of the pc" post I made is now out of context  even 




This thread which deals with about 20% of the scope of the post I'made at best.

My intention with this post is not to further the discussions on usb turning, potentially there is much broader and more profound points to be debated stretching across the PC and dac system.

If the post must be moved (although I fail to see why as it was the ,"hunting for noise" thread that started the in depth reporting on usb clock experimentation after all), it should be placed in a new thread please.

Nick.

[PeterSt]

Nick,

When you talked about jitter in your previous post, some neck hairs got upright here. So the answer to that is No, I don't think that this can be involved.
But I had another kind of response in mind which does not suite this topic anyway. The other one yes.

Peter

So now what I had in mind here;

What goes quite unnoticed for most if not all, is that I have been working on "stability" as such in the PC for a longer time; many of my posts in this topic should be seen through those glasses - but no need to read back on it.

Disclaimer on the idea : It will be impossible to reach total stability. That would mean a CPU response to all what is needed with the 100% exact same time response, like the 24000000Hz of the Dexa's in this topic should remain just that for ages. So, wobbling from, 24000001 to 23999999 many times per second already would not be that while the CPU response would be miles away from such a (implied) stability.
Still we can try to get as close as possible ...

Do notice that this now suddenly is about software (well, for me it always was, and if not explicitly said you can read it in between all of my lines) because when software does not imply steady load, how can the hardware - that implying the noise (changes) do that. So it has to start with software.

For what it is worth (and I myself can hardly believe (in) it :
Day before yesterday I achieved something which was in my mind for a long time : total stability as total can be (I have my means to check for that). Too bad that :

I was not able to stop the music which played flawlessly;
I was was not even able anymore to switch on the Monitor (and with that no clue whether the mouse still moved).
Without the 100% proof : a total lock up of the system, just with the goal of having it as stable as possible. Did I manage ?

Not important. What is important - and now read Nick's findings - is that it doesn't matter much which source we pull, as long as we "heavily" (up to heavenly) tune the noise for our best pattern;
It is not said (remember, all in my view) that it can be done by pulling one source only, but each source will have a kind of heavy influence once it oscillates heavily with the other.
Btw, tuning the memory frequency against the processor's also is a "known working" phenomenon; The PC is full of it.

I have some more to say at this moment, but maybe not too much in one post.
Peter

[PeterSt]

Nick,

Because to me all feels more like data loss than jitter influence ...

I don't know whether you have the equipment to do this :

Hook up that equipment to anywhere in the DAC hence at the end of the USB interface;
Capture a played track which probably needs to be very short so all can be captured in a one file to examine later (but if your capture can be infinitely large, a larger track is also good of course - even better).

- Start that playback and let the track die out;
- Trim it to the first visible music data at both ends (so no silence data is in there anymore);
- Make two runs of this, one with your sound "1" and one with your sound "3" (or anything, if only well audibly different).
- Compare the two captures for their length.

The thing you could be dealing with for false alarms is retransmissions, so I think the best would be to capture the i2s Data line (just one of the two).

In the mean time you could also try capture USB data itself, in front of the receiver chip, so you could proove retransmissions. Notice that this can be tricky for optimal results because you might tend to just observe raw USB data which comes in packets of fixed format and don't ask me at this time whether such a packed can be half full with real data, a header denoting that (and if so you won't be able to deal with it, unless a real USB logic analyser - and still).
So at first try to avoid this path (I think).

All obviously meaning :
When you can proove that especially first mentioned setup (capture i2s data) leads to the exact same length of data while the sound is totally different, then at least we can put that idea to the garbage can. So you know, this at least *is* something which can be physically checked for; how different patterns of noise influence jitter is quite something else for reliability testing.

No obligations of course, but the thing is damn important. So just look at this, when samples are discarded :

If so, ANYTHING done in the PC will matter; we can go as wild as we like. That the real solution is to get ourselves another means of playback is something else.

All 'n all this should have the priority because to me it is totally obvious that when data loss is in order all the remainder is completely moot.

Regards,
Peter

[PeterSt]

Something else : I find it quite confusing that this is now in this "noise" topic while the "trimming" tells it should be in that other one about *that*. So I think I will move this ...

[Edit : Which I just did, see the  "A consistent approach to PC / DAC tuning ?" posts.]

Regards,
Peter

Peter,

I think with the merging with this thread the "consistent tuning of the pc" post I made is now out of context  even 




This thread which deals with about 20% of the scope of the post I'made at best.

My intention with this post is not to further the discussions on usb turning, potentially there is much broader and more profound points to be debated stretching across the PC and dac system.
If the post must be moved (although I fail to see why as it was the ,"hunting for noise" thread that started the in depth reporting on usb clock experimentation after all), it should be placed in a new thread please.

Nick.

Emphasis is mine.

Yo Nick,

I think you didn't get what I tried to put across :

Firstly, the USB tuning is just one of the means to "get there". Well, you said or implied that yourself.
Next, there is one topic about that - with by now (your major post) the kind of proof of it.
Lastly, I do not want things to be scattered already for myself.

Maybe you (or all of you if you want) can deal with what is where and keep track of it, but I can not.
I sure thought of making it a new topic named "General trimming" or whatever, but then there would be a THIRD topic about it, if you only slightly thought it could fit in your "noise" topic (so by the grace of your own thinking it would be a third and I already don't like two).

Remember, *only* because it is not clear at this moment what causes which - but with the direction of "pick one", it is all the same subject, no matter this topic started out with USB-USB.

I can also tell you this - and I hope telling it one time is enough :
I plainly hate it that people start new topics while it actually is about a same or most similar subject as another one; Paul just did that with this topic (not you).
I plainly hate it when in all topics imaginable an ever the same subject arises about noise findings (you are prone to do that).
I regard it bad forum behavior when old posts are edited, no matter in another colour. Maybe the fact that you "can" do this makes us disagree on this little subject.

You may not be able to imagine, but when I see such a thing I say "oh no, not again !".

Hope it is clear now and/but also that it is clear that it is actually you (both) incurring for some moderation now and then. I do this for myself (hey, because *what* you guys spit out is considered important until proven otherwise) and in the end it should benefit yourselves (and not only yourselves).
I am not complaining (would have done so through PM when deemed necessary) - just responding. Defending if you want.

Best regards,
Peter

[PeterSt]

Digital jitter within the computer is a well known and understood phenomenon that is overcome with buffers and asynchronous protocols, but I am sure both you guys understand it.  I read an article a while back regarding design of sata cables to minimise jitter which was very interesting but long story.

Anthony, maybe I am a bit mean here (not intended so anyway) by putting this more out of context (leaving out the last part) then this text in itself already is. Read : even with your last part this can not be understood by any general layman.

So, no. Digital jitter in a computer is not at all understood, at least not by me. So go ahead with quoting from somewhere or putting links, which may help at least me.
Maybe the definition of "digital jitter" is about data arriving more late than originally intended, but it is no subject at all because all what happens inside a computer is one big pile of asynchronous (yes you used that in the by me left out part) operation. Call it buffers needed, call it synchronization timers or events - it is UNrelated.

I liked to put the emphasis on this, because you could be the first one proceeding on general ideas about in-PC jitter which does NOT exist. And then I mean : not for any relevance anywhere. Not for general processing of the whatever data and most certainly not for our audio.

But ...

When this can be brought down to such "synchronization" failing, it becomes a complete other matter, because then samples can be skipped or just as easy arrive (sent out !) in the wrong sequence. And mind you, for normal data this would not be a problem because each word in your Word document will find its place undoubtedly (and by guarantee). This is NOT the case for audio though because there's nothing at the other end reorganizing it.
Keep in mind : the audio data we talk about is sent in normal "data fashion" (not as audio) but it becomes time related (which is audio) after all when there's no method of getting it in the right sequence at the other end. This is not jitter, but plainly errorneous. How ? because it wasn't sent as should.

Btw, please don't mind the "wrong sequence" because this makes it unnecessary difficult. Just think skipped samples.

The real jitter (audio-thinking) can only emerge at the clocking out of the audio samples of the D/A chips. So if that clock is not stable it implies jitter (each subsequent sample is put out with slightly different time intervals).
That our precious oscillator is fed by unintened noise per unexplained noise paths, is 100% clear in itself;
That even a hardisks's movent of uneven draw from an SSD implies "uneven" noise is also totally clear (to me).
But see the bold text ...

Peter


PS: At using the Internet for telephone, one of your spoken words can follow many path all in small pieces (maybe even normal telephone lines do that). At my end all will be formed into the right sequence at the grace of the low sample rate giving it the time to do that (not that this really works, listening to Skype means etc.). Now, to put this to the extreme and how "digital jitter" for time UNrelated data can work, look at how a Torrent works. Know it ? All the millions of bits and pieces are SENT as one big random mess, even from dozens of PCs (seeders). But oh wonder, after your an hour of download all is in the proper sequence in the file. Yes, even your audio file won't have one bit wrong. Point is : the random mess was allowed to exist for that one hour long, because the sample rate can be considered "1 sample per hour". Thus, only after that one hour it needed to be correct (of sequence). Call it a buffer of one hour, and see the synchronization point exist at the point something tells the last bit (byte) is in.
Nothing of this can exist in audio, unless all can be done within the 1/786000 of a second for those samples which got mixed up etc.; It is not assumed to be working like this anyway, with one solution only : there must be a guarantee that each of those 768000 samples (which are 49152000 bytes) arrive at the DAC's end, with all needed to read them, put them to the interface, push it to the other end, and preferrably before our oscillator tells to clock them out which happens at 768000 times per second.

[CoenP]

Peter,

Wrt the dataloss, is it relevant for the USB interface? I mean that contrary to SPDIF, the USB interface will arrange for a resend if a fault is detected. How on earth can we else transfer programs over the interface that have to be "bit perfect' to work? There is no such thing as a lossy streaming over the USB async mode or is there?

Some psu experiments with the pp board suggest to me that is is all about noise patterns and that we neither want strong noise components nor large semi random spreads. What still puzzles me is the profoundness of this noise on the sound. Anecdotal reports on other forums suggest this is the effect a small amount of jitter entering the DACs can have.

regards, Coen