advertisement


MDAC First Listen (Part 00101001)

Status
Not open for further replies.
JohnW said:
I've been "getting to grips" with the USB interface and Regen - as the Regen will be a competitors product I'll have to be careful so as not to appear critical - I'll have to claim the 5th amendment if some question might force me into being too harsh about its design.

As a USB source I'm using a small Sony Pocket PC (VGN-UX380) and the USB connected via its docking station - running WinXP SP3.

Early days, so I'm just performing simple tests - but I can already see on a fast Analogue scope that the USB Packet it jitter visually effected by what the PC is processing - with eye pattern Jitter increasing from 320pS to 400ps simply by running a Youtube video.

The Screen is a mess and I'm just getting the feel of whats going on - while its easy to see the jitter modulation on the Analogue scope screen, I'm not sure how to post it here.... the screen is a mess....

You can see via the jitter modulation on the scope when the PC is performing other tasks - with big "apparently" random jumps in jitter, I suspect that these jumps are caused by other "hidden" operations being performed by the Windows OS.

I'm not in anyway endorsing the idea behind "optimized" media players (as the are trying to resolve an issue that should not effect the analogue domain in the first instance - IMO they are an indirect poor and dubious bodge fix) - but seeing the OS / CPU "Process" modulation comes as no surprise and opens a whole bag of hurt...

This observations are with the Upstream USB input to the Regen, it will be interesting to see if the USB hub is able to reformat the data packets and thus attenuate the OS / CPU process related jitter modulation.
Click to expand...

Hi john,

How is the scope triggering?
 
John
I may have misinterpreted your post but your findings so far seem to confirm that non-audio processes running in the CPU are a source of jitter. Have I understood that right?

So your mission John and Dominik, should you choose to accept it (once the FDAC and VFET and related projects are completed), is to design and produce a state of the art music renderer to feed files on a NAS or SD card to the FDAC . . . . The queue is already forming to put money down for the crowd funding :)
 
GWM said:
Will the Kelvin sense work in single ended mode via the 5 pin XLR as well.
Click to expand...

Possible, but you will only sense the 'positive' Signal and not the Ground return... SE interconnection is so sub optimal.
 
iansr said:
John
I may have misinterpreted your post but your findings so far seem to confirm that non-audio processes running in the CPU are a source of jitter. Have I understood that right?

So your mission John and Dominik, should you choose to accept it (once the FDAC and VFET and related projects are completed), is to design and produce a state of the art music renderer to feed files on a NAS or SD card to the FDAC . . . . The queue is already forming to put money down for the crowd funding :)
Click to expand...

USB eye pattern jitter.
 
BE718 said:
Hi john,

How is the scope triggering?
Click to expand...

I'm using a Tek11302 Analogue scope as its MCP Imaged intensified CRT allows me to look at the LF data frame packets at a 500pS Div timebase.

The scope is triggered on the the USB Sync Field - then I'm using the delayed timebase to look some 55nS later at an area of "Eye Patten" data traffic.

Casually looking a the scope the Sync field repeats at 8KHz, with significant data in 1KHz packets...

The Regen Board has both heavy 8KHz noise products with USB in idle state and 1KHz with data traffic. I've not tried phase noise measurements yet - but I can already tell from PSU modulation products that its going to be poor - the question is by how much will it improve the incoming datastream?

The designers of the SMSC USB2412 USB hub device used in the ReGen has taken zero care in its design of jitter attenuation as the upstream USB Data+ pin is located next to the Xtal_Out pin - that kills any pretense of decent Jitter and RF attenuation.
 
JohnW said:
I'm using a Tek11302 Analogue scope as its MCP Imaged intensified CRT allows me to look at the LF data frame packets at a 500pS Div timebase.

The scope is triggered on the the USB Sync Field - then I'm using the delayed timebase to look some 55nS later at an area of "Eye Patten" data traffic.
Click to expand...

Cool, do you need a diff probe?
 
iansr said:
John
I may have misinterpreted your post but your findings so far seem to confirm that non-audio processes running in the CPU are a source of jitter. Have I understood that right?
Click to expand...

Yes, on the USB Eye pattern - but the idea behind the Detox is to remove this undesirable CPU / System process related jitter modulation....
 
Quite interesting.

This reinforces my view that disabling all unessential Win processes is a good idea.

I have done just this with a Fanless Netbook running on Win7 and I am very happy with the resulting SQ and stability.
 
iansr said:
So your mission John and Dominik, should you choose to accept it (once the FDAC and VFET and related projects are completed), is to design and produce a state of the art music renderer to feed files on a NAS or SD card to the FDAC . . . .
Click to expand...

To my mind, the mission is to do what's being done at the moment: design a USB interface which removes these effects. And is therefore indifferent to the USB source device.

radamel said:
This reinforces my view that disabling all unessential Win processes is a good idea.
Click to expand...

Possibly it reinforces the idea of having an isolating USB interface
 
radamel said:
Quite interesting.

This reinforces my view that disabling all unessential Win processes is a good idea.

I have done just this with a Fanless Netbook running on Win7 and I am very happy with the resulting SQ and stability.
Click to expand...

Windows does its own things regardless, some variation will still be happening, but more to the point it doesn't establish there is a significant issue happening in the analogue dac output due to this.

John, with any of your previous testing have you established any correlation with the dac output?
 
BE718 said:
Windows does its own things regardless, some variation will still be happening (...)
Click to expand...

Not regardless. If you know what you are doing and you go for a bare bones win configuration many processes simply aren't run anymore. This is pretty easy to check.
 
radamel said:
Not regardless. If you know what you are doing and you go for a bare bones win configuration many processes simply aren't run anymore. This is pretty easy to check.
Click to expand...

OK..If you say so.....you would be wrong... but if you say so.....;)
 
radamel said:
Quite interesting.

This reinforces my view that disabling all unessential Win processes is a good idea.

I have done just this with a Fanless Netbook running on Win7 and I am very happy with the resulting SQ and stability.
Click to expand...
But .. but ... this is exactly what it is *not* about - what hifi/audiophile communities are so very good at - reinforcing one's view based on altered interpretation of the data. The details John posted don't tell you that less windows processes result in better SQ or even less RF noise - for all we know, more CPU processes could be better to bury the individual RF spikes and result in a more uniform spectrum. Or maybe not, somebody would need to measure it.

(Here's me hoping that JohnW's solution will do something similar, but on the USB interface itself, not by unnecesarily loading the computer, making an inefficient heater out of it.)

PS: My reasoning lies in what CPUs do when they're idle - it's an interesting problem that's nowadays solved by dedicated circuits and clock modes -- it's no longer the simple case of "just use NOPs in a loop" and switching between idle and non-idle might actually produce more spikes.
 
jirij said:
But .. but ... this is exactly what it is *not* about - what hifi/audiophile communities are so very good at - reinforcing one's view based on altered interpretation of the data. The details John posted don't tell you that less windows processes result in better SQ or even less RF noise - for all we know, more CPU processes could be better to bury the individual RF spikes and result in a more uniform spectrum. Or maybe not, somebody would need to measure it.

(Here's me hoping that JohnW's solution will do something similar, but on the USB interface itself, not by unnecesarily loading the computer, making an inefficient heater out of it.)

PS: My reasoning lies in what CPUs do when they're idle - it's an interesting problem that's nowadays solved by dedicated circuits and clock modes -- it's no longer the simple case of "just use NOPs in a loop" and switching between idle and non-idle might actually produce more spikes.
Click to expand...

Now what you are saying makes perfect sense.

In my particular case running fewer processes led to ending all pauses and clicks that I (seldom) had before. So a no brainer really.
 
radamel said:
Now what you are saying makes perfect sense.

In my particular case running fewer processes led to ending all pauses and clicks that I (seldom) had before. So a no brainer really.
Click to expand...

Well that just sounds like an underpowered Atom netbook struggling, although I have run jriver on a netbook without any particular issues or resorting to process management.
 
BE718 said:
Well that just sounds like an underpowered Atom netbook struggling, although I have run jriver on a netbook without any particular issues or resorting to process management.
Click to expand...

Yes. It was perhaps underpowered but not anymore.

OTOH I also tried an overpowered i7 with pretty dismal results.
 
Status
Not open for further replies.


advertisement


Back
Top