Lol, yes I forgot we have two ears and two channels.

Best regards,

Nick.

VJ hi,

768 by 32 bit requires bit transfer at 24.58Mhz. USB 2 in its fastest mode (used by the NOS1) has a carrier frequency on the cable of 480 MHz so even with the overhead of the USB protocol the 24.58mhz data transfer rate will not be a problem.

Where the cable bandwidth is important is that the link transfers data in short bursts carried at the 480mhz link speed so the cable needs to be good enough to accurately transmit the 480mhz carrier waveform.

Evidence is that there are a number of variables that go into making the transfer over USB run well, these appear to be linked to the accuracy of timing and electrical transmission and how effectively the data in at the receiving end can be clocked in. IMHO Cables are perhaps not the prime consideration but do have a role to play in getting the USB link to run well for music data.

Regards,

Nick.

Peter hi,

Thanks for the comments, they are very helpful.


I think the band width its fine for what the trace is highlighting. The scope used is just just a general 200mhz scope so it cannot get anywhere near the resolution needed to look at clock rise cycle jitter in the range of you super fast analoge sope. What is highlighting though is that the wave form distortions with the PC switched on that I’m seeing are so severe that they are easily picked up even on a scope of this type.

Even the basic mask function of the scope is easily triggered. As a note to exceed the mask shown in the trace the amplitude error has to be > +- 200mv or the time axis by > +-3 ns. That's bad repeating momentory external noise distortion on what is a low phase noise clock wave form.


We are thinking the same thing, to be honest I was a bit embarrassed to show the a clock wave form as messy as the attached. I am measuring at the clock’s output before coax to the mobo but at the injection point on the Mobo it’s much better.

I had opened an edit on the post straight after submitting it and started to write an addition to say that there is a possibility that scope’s probe ground set up might influence the observed wave form, but I did not update in the end.  The probes are ground referenced to PE which isn’t good with so much SMPS noise about becuase of the PE loop between the scope and mobo PE wiring. It would be nice to use a differential probe set up for this measurement.  I do have a second basic scope that has a floating probe ground (it can be battery powered) so I’ll take a look with this and also probe at the Mobo.

It’s a shame I cannot show the real time trace being displayed. The scope has digital phosphor persistence to show wave intensity and 50k refresh per second rate. When looking at the trace in real time, the main wave is solid but when the PC is running there is a constant flicker deviation of the wave form momentarily visible traces around the main wave. Looking at the real time trace switch mode noise seems likely, I was sort of expecting to see this but the noise source need to be proven if possible. It would be great if it were then possible addressed it.

Best regards,

Nick.


EDIT

I just looked at the trace and can see now why you mentioned ground bounce. The frame I have selected happens to break the mask just after the wave dropes to zero. I should have mentioned that when paging through the captured frames the mask errors occur througout the clock cycle. At the top the bottom and rise and fall phases of the clock cycle. This is why i'm thinking PC SMPS noise might be the source. The reason to for doing the frame analysis was to try to get a feel for the error frequency and to see if it had a pattern. I could use a decent FFT   

So its looking like various clocks within the PC interact with sound quality and that improving these clocks significantly improves sound.

I thought to run the clock waveform of the high quality clock through a basic mask test on my scope.

What the test does is first record a continuous waveform of the CPU source clock into the oscilloscope's memory for about 1/1000th of a second so in total about 25,000 clock waves are recorded. It is then possible to apply a test "mask" (see the blue area in the trace below which is incidentally a massive deviation for a clock signal)  to all of these waveforms so that the analysis captures each time a wave form shape deviates from unshaded area into the blue mask.

The wave form of a clock should be rock solid and not deviate all. When the clock being tested is captured without the PC turned on, sure enough the clock always stays within the mask and no errors are recorded.

With the PC turned in it is a very different story. The trace shows the capture analysis. The red circle shows one of the wave form errors picked up by the mask. In clock terms the wave form disruption is very large. That is really going to add jitter and phase noise.

Look now at the blue and red dotted lines at the bottom of the trace (see the lines between the white "1" and "2" in the image at the bottom). The trace from 1 to 2 in total represents about 1/1000th of a second in time. Every red dot on that line represents an error wave form that has strayed into the blue mask. This capture which is a typical one shows 444 errors in 1/1000 of a second. This equates to an average error rate just under 2 clock beats in every 100 !!

(Just as a note the trace shape shows reflections, due to the measurement point of the signal the wave form injected to the PC mobo is better.)

So this is driving thinking on further modification to the PC along another direction that I had hoped would not be necessary. I guess it is a case of how far you want to go, the sound quality so far achieved is very very nice, its just when you see this it points towards the possibility of more improvements.


Nick.

So a further update and to say its good news is somewhat of an understatement 

The high quality clock was put into by PC to replace the lashup clock that I reported on above. The result are spellbinding and the [fireworks]


 


are now official with bells and whistles on haha.

The new clock has only a couple of hours on it so it will significantly improve as it runs in but this is a no brainer of the first degree.

I will post more considered notes again when the clock has run in and I have had chance to properly setup the system [there is tuning to do that has not even been applied yet]. I’ve been researching what might be going wrong in the PC for a long time now and with all of the experiments over the last months can now target areas of the architecture that need to be "fixed", apply the fix and predict the results before hand with reasonable accuracy. In addition this is meaning that time is not getting wasted on stuff with limited payback potential. Parts for the next round of developments are on order but coming from China so frustratingly slow.

I just cannot believe how utterly broken a PC is for high quality music replay until it is "fixed". There is so much more to come I’m sure of more gains just need those dammed parts !

Mani and Paul are over this weekend so it will be interesting to see what they make of the sound..

Very very very  .... and more to come.

Nick.

Peter hi

I came across this paper on the relationship of environmental vibration on oscillators. Its fascinating reading.

http://cdn.intechopen.com/pdfs-wm/5975.pdf

Take a look at Fig 1 (PDF page 3), the figure and explanation are linking environmental vibration of an oscillator to increased phase noise at a phase noise offset frequency of the environmental vibration. Just look at the 100hz side bands in that plot ! So vibrate the crystal at 100hz and see the phase noise performance of the crystal get worse at 100hz offset. Or put another way audio or any frequency vibration results in similar frequency phase noise.

The paper is using high vibration G levels to prove the relationship but says it’s possible to work out a vibration susceptibility level which can be used to predict phase noise response to lower vibration G levels.

I'm not saying that the damping jitter effect is defiantly linked to oscillator vibration, there are plenty of other components in the PC that might be impacted leading to the jitter, but it’s interesting to see this. I guess also that the environmental vibration issue the paper discussed holds for any oscillator, so the audio oscillator in the DAC as well as the PC.

Now where did I put those isolation feet ? 

Regards,

Nick.

Hi Peter,

See what you mean, the scope is fast and could overwrite a transient response to the tap given the 25m refresh.

My thinking was that stimulus of a "tap" to the chassis is going to last for ~0.1 - 0.2 seconds (or you could drum your fingers continually).

Even with the exceptionally high refresh rate refresh there should be a good chance of seeing some transient reaction on the scope if the change in audio clock jitter performance is related to vibration within the PC.  The stimulus of drumming on the PC case should be large compared to vibration based feedback from playing of music, so if the jitter is vibration related you would think it would show itself.

Regards,

Nick.

Peter hi,

Could you set up so that you are playing music from the PC into the NOS1a but without your speakers switched on. Then try tapping the PCs chassis whilst watching the audio clock waveform to see if the taps on the PCs case / Mobo produce a transient spreading of the audio clock's trace line.

If vibration levels in the PC is linked to the audio clock jitter trying this might eliminate unintended variables between tests, and would really demonstrate a link between vibration stimulus of the PC and audio clock jitter in the DAC.

Regards,

Nick.

Peter


What a result, it's very exciting to see the traces above quantitatively linking the PC's "operation" to DAC jitter with vibration as the stimulus.  I'v also played around a little with vibration and EMI isolation here (eg moved the PC from the area of bass speakers, and placed clocks into enclosures etc) and it changed sound here too sometimes for the better, sometimes not.

There are the hardware level processes within the PC that have far greater linkage to sound quality, the PC's hardware "operations" massively influence sound quality. Certainly this is the case when using a DAC as transparent as the NOS1a but I'm reasonably sure now that virtually any DAC that uses a USB, Firewire or PCIe based interfaces will be very strongly influenced by PC's hardware.

Things have been slowed a little waiting for parts but lots of work is happening and more posts to follow 

Regards,

Nick.

An update on the PCIe clock.

The fireworks in my earlier post when the PCIe clock was fitted were just a small amount premature. .... BUT....

The lash test clock shows that the clock impacts music quality which is what it's intended to do. Overall some of the life and fun in the music took a small step backwards, although details were coming through and there was even less hash about in the sound. It's similar to using these "test" clocks in other locations, there is a well worn solution to shape up the sound however  yet another good quality clock and psu were ordered before Christmas. I'm confident that this will push things along a large amount when it arrives.

The real reason for this post is that having the PCIe test clock behave in this way has posed the question why ? This lead to some testing and further experimentation, which in turn lead to a work around which recovered sound quality and that appears to further support the theory of clock speed and quality linkage to music quality. The work around has also started to link into the picture the clock quality used to way transferred data into the CPU from the hard drive.

I have my fingers crossed that the new clock and psu arrive before I see Paul and Mani early this week. If not sound will not be quite as good as it has been but there are some very interesting demonstrations possible swapping master and PCIe clocks with one another and listening to the impact on sound.

Regards,

Nick.

VJ hi,

Yes the clocks being used here have their own psu. IMO this a one of a small number of factors that play into this area. Think the power environment of the standard PC clock feeds back and strongly influences the clock quality that a standard crystal set up can achive. It's proberbly not the only effect of a poor ATx supply or other sources of power rail noise in the PC but understanding now how closely linked clock quality and speed are to music quality I would bet money that cr*p in power rails is feeding in to the PC's timing.

So yes separate supplies on the clocks are being used.

Best regards,

Nick.

Mani hi,

Still have many of the list applied here. I've put notes in below.


Generally I'm still using a single drive, I can still hear USB connected drives in the system. I find Peters signature XX settings play best give or take some small variations. Same for Peters XXPC bios settings all seem to work together very nicely. For me the software and bios settings are still important in generating the magic, default bios and no OS optimisations in XX sound better since the NOS1a but the optimised settings work best here for SQ.

I bought an SSD a few years ago and could not get the OS to boot properly from it and actually wasn't a fan of the sound so went back to a spinning disk.

The PC mods are interesting they change the sensitivity to bios settings and clock speeds. I think with time I'll try to work through some bios and XX settings but I generally have kept coming back to Peters give or take a bit.

Really looking forwards meeting up at Paul's next weeks to catch up.

Kind regards,

Nick.

Hi,

The next clock was fitted to the Mobo today. To recap my PC now has the first upgraded master clock (for CPU memory etc etc) the second targeted clock to be fitted today that has just gone in is the PCIe signalling clock that runs timing as data moved from the south bridge to the PCIe USB card over the PCIe bus. The PCIe clock fitted today is actually one of my cheap clock modules as a lash up.

When I first listened to the PC with the second clock fitted it was immediately obvious that some aspects of the sound were now "super real" but that in the mids and highs all was not well, a bit of hash.

So going on the theory of relative clock speeds that is in part driving this whole process of upgrades to the PC, the CPU clock and the PCIe were tuned to the same speed (they were a long way out). The result was quite honestly a revelation..... 

followed by 

I will listen more before a more considered post on sound quality. For now I would describe the sound as EXTREME REALISUM : energy, detail, presence, tone etc etc, IMHO this is how to sort the PC as a music server. And this is with a quite low quality clock driving the PCIe sub-system, god knows what will happen when a dexa goes in.

More to come on sound soon

Nick.

ps Todd hi, I think you will need to get your master clock running at 25mhz. Matching this CPU clock to the PCIe clock is very important to get the music singing.
 

Todd hi,

I'm really pleased the mobo clock change has gone in well. And on a different mob type which is great. Nice to chat ealier it sounds as though your going to be catching up one some more live sounding favorite tunes 

Will post if tonight's experiments here work.

King regards,

Nick.

So this has been interesting and again points at how critical this mobo clock is. With the replacement crystal, sound is still massively better than without the upgraded clock. However the sound is changed. Right now bass is super taught and tuneful. Highs are clear and sparkle, there is richer tone but voices have an ever so slight halo making them not quite so madly detailed as before. The crystal has been in for 24hours and voices are improving quickly. It takes about a week for these crystals to run in and for jitter / phase noise to settle down so we will see. The interesting thing is that you can just hear the changes and that they are similar to problem elements of sound in the past.

I was refreshing on some research reading last night and the next mobo clock mod is well and truly on, if the idea is right (linked to the audio roulette thread) the next change might also be a big one.

Will post back.

Regards,

Nick.