advertisement


MDAC First Listen (Part 00101001)

Status
Not open for further replies.
The problem is that as soon as you allow any Data with Jitter yo enter the device it leaks RF energy and noise that's spectrally related to the Jitter - this then finds its way into the Analogue domain.

Having a memory buffer where numerous cells are clocked at the incoming "Jittery" clock rate just increases the number of active components radiating RF and Noise.

With adequate screening and care the effects can be reduced, but I prefer to eliminate the timing and noise issues before they enter the DAC then having to deal with there negative effects "afterwa.
Sorry for being dense but I'm afraid I still can't grasp why, assuming that some sort of noise/ radiation is created every time a bit is read by the USB recover or read into a buffer, the noise is dramatically worse if the bits are read in slightly unevenly. (Especially bearing in mind that the USB data is sent in bursts anyway not in a regularly spaced steam like S/PDIF) I understand that the jitter frequencies might be present in the noise, but does that make it worse?
 
Yes I have thanks. There is a suggestion that more noise would be created if the USB receiver has to try hard to read the data. But how bad does the data steam have to be for this effect to cut in, and how significant is the effect? No one has as far as I know ever demonstrated any of it. I'm afraid it all smacks of audiophile Ethernet cables and linear psus on the router.
 
I understand that the jitter frequencies might be present in the noise, but does that make it worse?

Yes - this is the fundamental problem the Phase noise of the jitter spectrum is heavily modulated by what ever the Host USB device happens to be processing, its PSU noise, and mixed in with the Audio Data - a whole "bucket load of crap".... the Phase noise of the data is really really bad! PC's are designed just to work, without any regards to how much unwanted energy they spew out - just as long as they conform to EMC regulations.

Your welcome to visit my lab here in Czech Rep. sometime and I can demonstrate the kind of artefacts that need to be dealt with - I have real time spectrum analysers that can perform 3GHz real-time FFT spans of the RF energy - its horrifying, sometimes your not even sure where to start...

You can measure this noise on the DAC's ground plane - and this is the root problem that even a single logic gate operating will inject noise onto a Ground plane - so you don't want this logic Gate to be "processing" any data pattern that has unwanted phase noise encoded onto it.

Its better to prevent the toilet overflowing then having to deal with the Crap on the floor afterwards!
 
There is no simple way to isolate USB 2.0 at the full High Speed data rate of 480Mbps which is required for Audio sample rates above 96KHz.
Well, it's a bit more complicated than USB1.0 or 1.1, but not impossible. IIRC the problem was doing it sufficiently fast to meet the few-nanosecond limit between two endpoints and achieve transparency. (It's quite a few analog-logic-based steps; http://www.usbmadesimple.co.uk/ums_6.htm#negotiating_high_speed.)
However noone says you can't implement a legitimate USB hub that presents itself in the device tree and uses transaction translators (TTs) for split transfers for USB1.1 devices. Being a "full blown" hub also (as far as I know) lifts the tight timing limitations as you can insert the filtering logic between the host-side and the device-side (something you can't do witch IC-based hub chips).

Or would basically implementing a hub "from scratch" be too much work?

Another alley to investigate would be the usb-to-ethernet adapters that presumably do the mandatory galvanic isolation on the RJ45 jacks ("magnetic coupling"), for safety reasons. The idea (as well as with the $400 optical extender) is basically what I described above as a hub implementation, using a custom protocol (that isn't tied to the electrical limitations of USB) to "isolate" the endpoints, isolation here actually being a side effect.
 

I personally have a different point of view - I don't agree with JS understanding of the issue at hand.

The timing of the USB data packets from the PC are heavily influenced by the local system noise (the Data patterns of the CPU / BUS is processing) - many years ago I work with a certain embassy in the UK to prevent their computer systems from leaking secrets via unintentional RF emission. We are able to literally reconstruct the screen image of a standard PC from the opposite side of the road.... We used a two prong hardware and software solution to attenuate & scramble the emissions.

The USB "ReGen" hub device re-buffers the USB data stream with its own local clock rather then the PC's internal Clock / USB host which thesedays are integrated into the Motherboards South-bridge device a true rats nest of correlated data patterns.

The Timing of the 8KHz USB packets unintentionally encodes the HOST system noise - its not about the signal integrity that matters (as long as the data can be recovered), rather the encoded phase noise of these packets... there location in time! its all about time - and unwanted 'RF' energy.
 
So it's not a better mousetrap we need, it's a better toilet ;-) In this case the toilet is the music renderer device that outputs the digital music signal via USB. I'm currently playing around with a Pi 2 as a renderer in the belief that it will be generating less crap than say a PC because all it is doing is rendering the digital signal and not running lots of other processes in the background. But what do I know . . . .
John are you aware of any music renderers, either commercially produced for the purpose or adapted like the Pi and other SBCs, that successfully minimise the crap down to an acceptable level?
 
Or would basically implementing a hub "from scratch" be too much work?

If you wanted to buy a USB 2.0 IP core your literally talking millions of dollars!

Thats why its taken so long for USB 2.0 to appear on lower-end MCU's - they are more common today - USB 2.0 IP is very expensive.
 
So it's not a better mousetrap we need, it's a better toilet ;-) In this case the toilet is the music renderer device that outputs the digital music signal via USB. I'm currently playing around with a Pi 2 as a renderer in the belief that it will be generating less crap than say a PC because all it is doing is rendering the digital signal and not running lots of other processes in the background. But what do I know . . . .
John are you aware of any music renderers, either commercially produced for the purpose or adapted like the Pi and other SBCs, that successfully minimise the crap down to an acceptable level?

The Pi2 is a simpler computer platform so well have less "encoded" phase noise - but its still orders too noisy - A well designed USB ReGen and RF filtering with Isolation is the real solution, a multi stage approach as each stage will only a attenuation a certain level of encoded phase.

USB Hub devices with their lousy on-board PLL / Clock circuits are not designed to attenuate Packet Jitter - they happen to do so by being a "repeater / routing" logic block - but Phase noise attenuation is not a design consideration - only to meet the Eye Pattern Spec. not the spectral content of the Eye pattern.

With a little care, a self powered USB hub can have much lower phase noise on their USB packets then any Host PC device.
 
If you wanted to buy a USB 2.0 IP core your literally talking millions of dollars!

Thats why its taken so long for USB 2.0 to appear on lower-end MCU's - they are more common today - USB 2.0 IP is very expensive.
Ah, I didn't realize how locked down that thing is on the hardware level. Oh well, there's some fun ruined.

You might as well take a look how the ethernet device works if you want, here's the reference article and the exact device used. Somehow I don't think it's a simple signal amplifier.
edit: Apparently it goes well with a fully shielded cable (STP/FTP) as the RF tends to leak back in right after the source endpoint when using UTP. I know a really nice shop in Brno that sells just about any kind of cable. :)

edit2: I understand if you decide to go for the USB1.1-only version (to keep things simple and focus on the goal at hand - testing the production pipeline, saving time for MDAC2) rather than making The World's Best Ultimate USB 4.0 Isolator. PS: I want one. Or two.
 
hi Guys

It's been awhile since I've been on the forum.

I noticed the posts regarding the bulging cap issue with the MDAC. I would like to take the cover off to check if this is a problem with mine.

Can anybody give me any tips on how to remove the cover, including the torx driver size.


Thanks
Mike


Is this cap issue a problem with all Mdac's or is it problem with a certain run?
 
Yes - this is the fundamental problem the Phase noise of the jitter spectrum is heavily modulated by what ever the Host USB device happens to be processing, its PSU noise, and mixed in with the Audio Data - a whole "bucket load of crap".... the Phase noise of the data is really really bad! PC's are designed just to work, without any regards to how much unwanted energy they spew out - just as long as they conform to EMC regulations.

Your welcome to visit my lab here in Czech Rep. sometime and I can demonstrate the kind of artefacts that need to be dealt with - I have real time spectrum analysers that can perform 3GHz real-time FFT spans of the RF energy - its horrifying, sometimes your not even sure where to start...

You can measure this noise on the DAC's ground plane - and this is the root problem that even a single logic gate operating will inject noise onto a Ground plane - so you don't want this logic Gate to be "processing" any data pattern that has unwanted phase noise encoded onto it.

Its better to prevent the toilet overflowing then having to deal with the Crap on the floor afterwards!
John, this is really fascinating stuff. Could we not load an album of music into a well designed massive buffer in the DAC, disconnect the PC then listen in the lounge with the toilet door well and truly shut? If it were this easy I suppose SD card players would all sound good.

I personally have a different point of view - I don't agree with JS understanding of the issue at hand.

The timing of the USB data packets from the PC are heavily influenced by the local system noise (the Data patterns of the CPU / BUS is processing) - many years ago I work with a certain embassy in the UK to prevent their computer systems from leaking secrets via unintentional RF emission. We are able to literally reconstruct the screen image of a standard PC from the opposite side of the road.... We used a two prong hardware and software solution to attenuate & scramble the emissions.

The USB "ReGen" hub device re-buffers the USB data stream with its own local clock rather then the PC's internal Clock / USB host which thesedays are integrated into the Motherboards South-bridge device a true rats nest of correlated data patterns.

The Timing of the 8KHz USB packets unintentionally encodes the HOST system noise - its not about the signal integrity that matters (as long as the data can be recovered), rather the encoded phase noise of these packets... there location in time! its all about time - and unwanted 'RF' energy.
I have so many questions! Since I've been using the Regen I've noticed greater differences between software players and usb cables. I'm not deeply into usb cables and I don't find differences correlate with price, often the reverse in fact.

USB Cables
With Regen I've confirmed a view (to myself) that short cables sound better. I have a few 15cm cables (or shorter), a 50cm and some 1m. The 15cm and 50cm cables are of very similar construction and all totally omit the 5V wire. I'm finding that the the 50cm and 1m cables give the music a slight metallic sheen. The shorter cables do not do this. I would have thought they will all transmit the same RF into the DAC; is it possible the longer cables are also working as more effective RF aerials?

Software Players
I know that some software developers claim to be reducing noise being transmitted by PCs. Techniques include:
- writing render loops in assembler + other coding techniques, eg using SSE & AVX instructions
- using 2 specific registers on Intel CPUs which sound better
- rewriting memory before playing
- laying out files in double sided / dual channel memory
- playing back in hibernate mode or with the display blanked

If the above techniques change or improve the RF characteristics of the PC then it's no surprise software players can differ in sound.

Does this chime with your RF measurements?
 
Is this cap issue a problem with all Mdac's or is it problem with a certain run?

Mike,

As I no longer work with IAG / Audiolab I don't have access to the data - but I suspect some batches are worst then others as I have a CDQ (that uses the same caps and operates much hotter then the MDAC) and its been powered for almost 5 years without bulging caps...

But this is only circumstantial evidence.
 
John, this is really fascinating stuff. Could we not load an album of music into a well designed massive buffer in the DAC, disconnect the PC then listen in the lounge with the toilet door well and truly shut? If it were this easy I suppose SD card players would all sound good.

The MCU we are planing to use for the FDAC Digital board has a SDcard interface, I was considering adding a SDCard reader to the FDAC so that later we might release a software update (lots of work) that could read and write to the SDcard - Mainly to be able to offer an all in one recorder / or test system.

Software Players
I know that some software developers claim to be reducing noise being transmitted by PCs. Techniques include:
- writing render loops in assembler + other coding techniques, eg using SSE & AVX instructions
- using 2 specific registers on Intel CPUs which sound better
- rewriting memory before playing
- laying out files in double sided / dual channel memory
- playing back in hibernate mode or with the display blanked

If the above techniques change or improve the RF characteristics of the PC then it's no surprise software players can differ in sound.

Does this chime with your RF measurements?

This opens a whole bag of hurt - dear Adam here on PFM will be rolling around in discomfort!

I can see how the varying CPU process produces different RF / Jitter spectrum and this is a fact of life - what's not tolerable is that this makes its way into the Analogue domain. I myself have heard such effects myself and am not proud - it indicates design limitations with the audio system and as an audio designer I have to share the blame.

Computers will radiate all kind of nasties - they are horrid is this regards so we need to accept this as a fact of life and tackle the problem head on.

I slept on the ideas last night and really want to design this USB Detox ( :) ) interface as I'd be avoiding the elephant in the room to ignore the multitude of problems posed by connecting a computer to the audio system. I've always stressed that the RF and Jitter should be dealt with BEFORE they are allowed to enter the DAC enclosure - this holds true for the MDAC and FDAC.

The design is a quick task, the production will be interesting, but I'm really keen to "send a simple design down the production line before the FDAC PCB's" so it makes this little project even more interesting.

If there is significant interest then it will take less then a week to design the PCB.

As each USB Hub device only offers a certain "limited" level of attenuation I'll cascade 3 devices in series each with there own PSU and Clock interface, this will add extra cost - but its the correct way to design the board.

Lets to a proper job of this :)

I'll use these RF screen tins for each Cascaded attenuation stage and the Master clock circuit:-

http://www.teko.it/en/prodotti/famiglia/RF/serie/49

So the design will look something like this:-

USB input

RF Filtering

1st Hub

RF filtering

2nd Hub

RF filtering

3rd Hub

USB 2.0 480Mbps USB output (Non Isolated) + RF Filtering

USB 1.1 12Mbps galvanically isolated USB output + RF filtering

There will be two toggle switches to enable the Clock-lock interface + Spectrum decorrelation mode (Enables a random spread spectrum clock source).

Development fee GBP50 + unit sold at cost say around GBP80 payable once we start to manufacturer the PCB's.

If we have say 20 PFM'ers interested then I'll launch the project and spend an hour or 2 designing the PCB each night.
 
Computers will radiate all kind of nasties - they are horrid is this regards so we need to accept this as a fact of life and tackle the problem head on.

I slept on the ideas last night and really want to design this USB Detox ( :) ) interface as I'd be avoiding the elephant in the room to ignore the multitude of problems posed by connecting a computer to the audio system. I've always stressed that the RF and Jitter should be dealt with BEFORE they are allowed to enter the DAC enclosure - this holds true for the MDAC and FDAC.

The design is a quick task, the production will be interesting, but I'm really keen to "send a simple design down the production line before the FDAC PCB's" so it makes this little project even more interesting.

If there is significant interest then it will take less then a week to design the PCB.

As each USB Hub device only offers a certain "limited" level of attenuation I'll cascade 3 devices in series each with there own PSU and Clock interface, this will add extra cost - but its the correct way to design the board.

Lets to a proper job of this :)

I'll use these RF screen tins for each Cascaded attenuation stage and the Master clock circuit:-

http://www.teko.it/en/prodotti/famiglia/RF/serie/49

So the design will look something like this:-

USB input

RF Filtering

1st Hub

RF filtering

2nd Hub

RF filtering

3rd Hub

USB 2.0 480Mbps USB output (Non Isolated) + RF Filtering

USB 1.1 12Mbps galvanically isolated USB output + RF filtering

There will be two toggle switches to enable the Clock-lock interface + Spectrum decorrelation mode (Enables a random spread spectrum clock source).

Development fee GBP50 + unit sold at cost say around GBP80 payable once we start to manufacturer the PCB's.

If we have say 20 PFM'ers interested then I'll launch the project and spend an hour or 2 designing the PCB each night.


Count me in. John you do realise that one post over on the CA forum and you you will be able to sell these by the container load. So after this initial run I suggest you set a sensible price that includes a reasonable profit margin, tell your manufacturer to brace himself and offer them to the world. It will more than solve the funding problem of the salvaged MDACs!
 
If we have say 20 PFM'ers interested then I'll launch the project and spend an hour or 2 designing the PCB each night.

I think it's the right way to go John considering the positive impact I've noticed in my system from the Regen.

Would have jumped onboard if I wasn't already covered by my PPA USB v2 and Regen both powered by an LPS.
 
Status
Not open for further replies.


advertisement


Back
Top