Amir's Music Server Build Thread

[Mivera]

When I test DAC's without galvanic isolation on the USB interface, I can clearly hear differences between different connected computers, and supplies. With Galvanic isolation, it helps reduce the differences, but doesn't sound as good as the galvanic isolation adds jitter. It wasn't until I tested the Phison PD2 with both galvanic isolation, and reclocking via flip flop that I heard no differences between connected computers.

 

[Mivera]

Oh and feel free to install the Linux version of Roonserver on a USB stick, or M2 drive to try out on my NUC while you have it.

 

[Opus111]

Even stranger is buying a linear power supply, then feeding it to a module inside the PC that generates all the various voltages required using switchmode power supply!

That's different - the primary problem of SMPSUs connected to the mains side is common-mode noise. Switchers connected to the secondary side don't have a mechanism for generating CMnoise - they can still generate normal-mode noise though which is normally (ha!) not an issue.

 

[Fitzcaraldo215]

When I test DAC's without galvanic isolation on the USB interface, I can clearly hear differences between different connected computers, and supplies. With Galvanic isolation, it helps reduce the differences, but doesn't sound as good as the galvanic isolation adds jitter. It wasn't until I tested the Phison PD2 with both galvanic isolation, and reclocking via flip flop that I heard no differences between connected computers.

How is jitter a problem with asynchronous USB?

 

[Mivera]

How is jitter a problem with asynchronous USB?

Because it is clocked digital data. Whenever you have digital data that is clocked, jitter is an issue. The Async is just a method of jitter reduction.

 

[Opus111]

You said 'galvanic isolation adds jitter' - how does it do so in the case of async USB?

 

[Mivera]

You said 'galvanic isolation adds jitter' - how does it do so in the case of async USB?

Because the Async doesn't completely remove the jitter. It only reduces the jitter. This is why the best USB interfaces do another reclock after the isolators and clocks. But the compromise is you half your clock frequency. Or you need twice the clock speed to get the same clock speed in the end. Higher speed clocks have more jitter. But with Sonny an my experiments, we found that reclocking with higher jitter, higher frequency clocks, a better end result was obtained than no reclocking with much lower jitter clocks. Plus far superior isolation.

 

[Opus111]

'Remove the jitter' seems to be to be based on a misunderstanding of the nature of 'the async'. There's no 'removal of jitter' taking place with async as there's nothing but asynchronous data coming over the link from the PC. Only time-sensitive (i.e. synchronous) data would need to have jitter removed.

'Another reclock' after the isolators means nothing in an engineering sense, might help with marketing though.

 

[Mivera]

'Remove the jitter' seems to be to be based on a misunderstanding of the nature of 'the async'. There's no 'removal of jitter' taking place with async as there's nothing but asynchronous data coming over the link from the PC. Only time-sensitive (i.e. synchronous) data would need to have jitter removed.

'Another reclock' after the isolators means nothing in an engineering sense, might help with marketing though.

The extra complexity of reclocking was not done for marketing. That would be completely stupid because far lower jitter clocks are available in 22/24mhz than 44/48. It was done because the sound is much better, and provides superior isolation from noisy connected sources.

 

[Fitzcaraldo215]

Because it is clocked digital data. Whenever you have digital data that is clocked, jitter is an issue. The Async is just a method of jitter reduction.

Just to be clear, we are talking about jitter introduced in the transmission and receiving stages. Yes, of course, there is jitter internal to the DAC itself. This does not go away regardless of the transmission medium or protocol, including asynch USB. But, asynch USB is not, in fact, just "clocked digital data" in the same way that spdif, for example is. The clock has moved from the player to the DAC, which is extremely significant. Amir has a relevant article in the library here, somewhere.

I am actually stunned, after all your techie hootin' and hollerin' about this and that in DACs that you fundamentally do not get this. This is important stuff. You think you can just brush it aside with techie talk. But, I think I see right through you, my friend.

 

[Opus111]

Why would reclocking be done for non-marketing reasons? If there's an engineering reason for it (and its possible I'm missing something vital) then do please explain what it is?

With async USB there's only clocking, never any reclocking. 'Reclocking' would mean some previously synchronous data had gotten out of whack and needed to be straightened up, but the nature of async is that this can't ever be the case.

 

[Mivera]

Just to be clear, we are talking about jitter introduced in the transmission and receiving stages. Yes, of course, there is jitter internal to the DAC itself. This does not go away regardless of the transmission medium or protocol, including asynch USB. But, asynch USB is not, in fact, just "clocked digital data" in the same way that spdif, for example is. The clock has moved from the player to the DAC, which is extremely significant. Amir has a relevant article in the library here, somewhere.

I am actually stunned, after all your techie hootin' and hollerin' about this and that in DACs that you fundamentally do not get this. This is important stuff. You think you can just brush it aside with techie talk. But, I think I see right through you, my friend.

All Async does is buffers a bit of the data from the computer, and reclocks it with another clock. It's this process that reduces jitter. I never claimed that it reduces that jitter that occurs between the USB interface and the DAC chip.

 

[Mivera]

Why would reclocking be done for non-marketing reasons? If there's an engineering reason for it (and its possible I'm missing something vital) then do please explain what it is?

With async USB there's only clocking, never any reclocking. 'Reclocking' would mean some previously synchronous data had gotten out of whack and needed to be straightened up, but the nature of async is that this can't ever be the case.

The reclocking I'm talking about in this case is done with a flip flop after the clocks on the USB interface.

 

[Opus111]

But, asynch USB is not, in fact, just "clocked digital data" in the same way that spdif, for example is.

Right - jitter in an S/PDIF context makes sense, there are papers on this going back to Hawksford's seminal 'Is the S/PDIF interface flawed?' for the AES eons ago.

The clock has moved from the player to the DAC, which is extremely significant.

Right again - the data coming from the PC is no longer short-term time sensitive and hence jittered by design (in that its sent in bursts so the jitter by audio standards is huge, well above microseconds).

 

[amirm]

All Async does is buffers a bit of the data from the computer, and reclocks it with another clock. It's this process that reduces jitter.

Mike, re-clocking implies tight connection between the two ends. This doesn't exist in async operation. I would call it "clocking it." The USB clock is thrown away for this use.

 

[Opus111]

The reclocking I'm talking about in this case is done with a flip flop after the clocks on the USB interface.

But it would be a reclock with the same clock - the local one - so accomplishes nothing that I can see. Which is why I mentioned the possibility that marketing might like such needless complexity.

 

[Mivera]

Mike, re-clocking implies tight connection between the two ends. This doesn't exist in async operation. I would call it "clocking it." The USB clock is thrown away for this use.

Well it's not the same as the reclocking like the flip flop does. But there's 2 clocks and it goes from 1 clock speed to another so to me that's reclocking as well. But I suppose if we only look at it from downstream from the point it's buffered, than its just being clocked.

 

[fas42]

That flip flop is perhaps guaranteeing a cleaner transition between states before being fed to the DAC, but it's not a clocking operation - effectively it's a buffer/filter in its operation.

 

[Mivera]

But it would be a reclock with the same clock - the local one - so accomplishes nothing that I can see. Which is why I mentioned the possibility that marketing might like such needless complexity.

People aren't doing it because it accomplishes nothing. It reduces jitter. The Phison PD2 does it, as well as the JLsounds board:

http://jlsounds.com/i2soverusb.htm

And the Acko reclocker:

http://www.diyaudio.com/forums/group-buys/227502-amanero-isolator-reclocker-gb-141.html#post4145456

 

[Opus111]

http://jlsounds.com/i2soverusb.htm

Link returns a 404 error.

http://www.diyaudio.com/forums/group-buys/227502-amanero-isolator-reclocker-gb-141.html#post4145456

Link shows plenty of eye candy but no explanation for how it might be necessary.