M2TECH Hiface USB->SPDIF 24/192Khz asynch

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Administrator
Joined 2004
Paid Member
I believe the ESS DAC senses the speed of the incoming data & reclocks it with it's own local clock.

From the ESS white paper their DAC ignores the incoming clock, tears the signal apart and reconstructs it with an internal clock. Quite how they do that, I don't know - but the white paper is here:
http://www.esstech.com/PDF/sabrewp.pdf

It seems to work, it's a smooth sounding chip.
 
From the ESS white paper their DAC ignores the incoming clock, tears the signal apart and reconstructs it with an internal clock. Quite how they do that, I don't know - but the white paper is here:
http://www.esstech.com/PDF/sabrewp.pdf

It seems to work, it's a smooth sounding chip.

Not strictly correct, listen to what Dustin has to say
You are right about the SPDIF, when using that input mode, you MUST use the ASRC, when using the DSD or PCM inputs the ASRC is optional and can be bypassed altogether.

So for I2S or DSD you have the option of using the ASRC (as glt rightly says) or not. Gordon says that avoiding the ASRC is the lower jitter option BUT as labjr pointed out to me, ESS recommends for best performance, MCLK > 256fs if using I2S (384fs using SPDIF)

Now, in the HiFace the chip responsible for SPDIF/I2S output, DIT4192, uses 128fs at 176.4 and 192kHz; 256fs at 88.2 and 96kHz; 512fs at 44.1 and 48kHz.

I run my HiFace into the ES9022 DAC which has a similar requirement & it sounds great but maybe not optimal at 192KHz & 176KHz? I don't have much material at this samplerate & probably won't be getting too much.

I'm experimenting with asynch MCLK (provided from a local clock - need to get a 50MHz one) & if it sounds better I'll probably go this route.
 
Jekny,

Logically I would think synchronous clocks from the hiface would sound better than a 50Mhz clock running asynchronously from the DAC. But I haven't compared Why not use an 80MHZ clock or will that not work with the ES9022. If the clockspeed in hiface could be doubled then maybe it would be ideal.

Of course good sound comes from implementing everything well. Metric Halo is beating the pants off the competition with while using internal switching supplies, etc and selling for far less money making it a great value.
 
Jekny,

Logically I would think synchronous clocks from the hiface would sound better than a 50Mhz clock running asynchronously from the DAC. But I haven't compared
Yes you've said this before but I'm not sure that this is logically correct! What's you're line of thinking for this?

Why not use an 80MHZ clock or will that not work with the ES9022. If the clockspeed in hiface could be doubled then maybe it would be ideal.
Yes ES9022 doesn't sound good on 80MHz or on 24MHz - I've tried both speeds before I did the mods to the HiFace - might be worth revisiting these clock experiments again - they sounded fine at lower sample rates up to 192KHz where there was a ringing around the sound!

Of course good sound comes from implementing everything well. Metric Halo is beating the pants off the competition with while using internal switching supplies, etc and selling for far less money making it a great value.
Switching supplies can be done well - it just seems to take a lot of work to get right!
 
Yes you've said this before but I'm not sure that this is logically correct! What's you're line of thinking for this?


If I'm understanding this correctly my line of thinking is that if all the data is transferred by one ultra low jitter clock then there's no chance some PLL servo circuit will mess up the transfer into the DAC causing jitter. As good as the Asynchronous transfer in this DAC may be the best is can probably be theoretically is approaching synchronous transfer so why not start with the approach we know will give low jitter.

I have to admit, what I don't quite get why it is that asynchronous transfer by USB would be good but when transferring from the input receiver to the DAC synchronous transfer would be better. I guess because the jitter from the PC clock has to be removed. Basically reclocking isn't it? So why keep messing with reclocking except when you need to.


Switching supplies can be done well - it just seems to take a lot of work to get right!

Yeah there's one inside your DAC !
 
If I'm understanding this correctly my line of thinking is that if all the data is transferred by one ultra low jitter clock then there's no chance some PLL servo circuit will mess up the transfer into the DAC causing jitter. As good as the Asynchronous transfer in this DAC may be the best is can probably be theoretically is approaching synchronous transfer so why not start with the approach we know will give low jitter.
Ah, I understand your line of thought BUT in the transporting of this low jitter clock many things can go wrong - cables, impedance mismatches, clock recovery, etc so like in the case of USB some would say that a local clock feeding the DAC is the best solution. Now this local clock can be synchronised with the data (ie fed back to the transport) or it can be asynchronous with the original data timing. If the transport mechanism is I2S & the signal lines are kept short then it's possible that not much extra jitter has been introduced to the original clock. If the transport mechanism is SPDIF then all sorts of problems raise their head & the potential for adding jitter is higher, I believe.

So it's all down to implementation yet again!

In the case of the Sabre DACs it would seem that their particular way of doing ASRC is less detrimental to sonics then other ASRCs & there probably isn't as big a sonic penalty to go asynchronous. In my brief experiments with asynch clocking on this ES9022 DAC there was no loss in sonics with asynch clocking but no gain either that I could hear. I only tried 2 clock speeds initially a 80MHz clock which gave a strange sound to 192KHz material & a 24MHz clock which also gave a strange but different sound to 192KHz material & maybe 176KHz too. I think maybe somewhere around 50mHz is the optimal clock speed?

I have to admit, what I don't quite get why it is that asynchronous transfer by USB would be good but when transferring from the input receiver to the DAC synchronous transfer would be better. I guess because the jitter from the PC clock has to be removed. Basically reclocking isn't it? So why keep messing with reclocking except when you need to.
It's needed in USB!

Yeah there's one inside your DAC !
A switching supply as in a charge pump, yep & it does sound good!
 
Have been playing with my HiFace connected to ES9022 DAC & it has caused me to consider issues that I had ignored up to now (again thanks to Labjr for highlighting these issues for me):

The MCLK speed versus data sample rates.

For instance the HiFace uses MCLK of 128*fs for 176.4 & 192KHz; 256*fs for 88.2 & 96KHz; 512*fs for 48 & 44.1KHz. Now the ES9022 datasheet says "For best performance 256*fs or greater is recommended for 32KHz to 96KHz sampling" So at 176.4 & 192KHz sampling this combination of HiFace & ES9022 is not optimal - I need to do some comparative listening at 192KHz (versus Musiland transport).

I will order a 50MHz clock soon & try this in asynchronous mode soon. So maybe another reason why in the case of ESS DACs anyway, asynch clock is not such a bad idea or else some care has to be exercised in selecting what feeds the ESS range of DACs!
 
I seem to remember reading that the asynchronous clock speed should be a non integer multiple of the fs but I can't remember where. Can anybody put me out of my misery with a link or clarification?

Yes you are right. The DAC auto-detects whether the Clock is synchronous or not. But what's the difference? So it's synchronous for one sample rate but not the other. The only thing the thing that matters is the jitter on the clock input.
 
Hmm, I'm not so sure - have you got that on good authority?

I'm not positive about my entire statement, but the part about the auto-detect is true from the horses mouth. What I don't understand is how running in asynchronous or not affects the timing of the rest of the circuit (I2S clock, MCLK for the input receiver.

I think we need to appoint Dustin an honorary moderator and contributor to the Digital forums. Because some of this is hard for me to grasp. I have a million questions and I feel like I'm a long way from being able to actually build a DAC that works.
 
I'm not positive about my entire statement, but the part about the auto-detect is true from the horses mouth.
Yes, I know it auto-senses the input data rate but I don't think that the DAC moving in & out of synch with the data would be good!
What I don't understand is how running in asynchronous or not affects the timing of the rest of the circuit (I2S clock, MCLK for the input receiver.

I think we need to appoint Dustin an honorary moderator and contributor to the Digital forums. Because some of this is hard for me to grasp. I have a million questions and I feel like I'm a long way from being able to actually build a DAC that works.
Understanding all this requires a lot of deep knowledge about how DACs work & then how the particular DAC works - this is not readily available or forthcoming on DIY forums :)
 
Yes, I know it auto-senses the input data rate but I don't think that the DAC moving in & out of synch with the data would be good! Understanding all this requires a lot of deep knowledge about how DACs work & then how the particular DAC works - this is not readily available or forthcoming on DIY forums :)

It seems the people with the talent in digital are cashing in. I don't we'll be lucky enough to get a Nelson Pass in the digital forums.
 
I re-worked my Musiland 01US to use a socket for I2S so that my ESS DAC could plug into it. Well the modded HiFace leaves the modded Musiland in the dust. The Musiland has everything done to it that can be done
- disabled all switching regs
- disabled power to DAC & output op-amp
- replaced PS de-coupling caps with larger uf OSCONs
- external clean 5V supply replaced USB 5V (as per the HiFace)
- short I2S to DIP8 socket glued to top of Xilinx chip

The HiFace has better clarity all through the frequency range
- bass is amazingly textured & powerful
- treble has an airiness to it
- finer details are revealed
- soundstage is deep & wide with venues & recording ambience being revealed clearly
- as I said already, just like really good analogue, not a bit of digititis in it. Last night I listened for about 4 hours through headphones without a hint of harshness or headache :)
- This unit really is a killer when modded - I would love to hear others try it & report their impressions! It would be interesting to hear how it compares against some of the big ticket Transports/DACs (Ayre, Wavelength,dCs, etc) - I don't own or have access to these units :)

So, I'm thinking of completing the final mods to the HiFace
- replace the 1.2V reg with external clean 1.2V supply
- It just dawned on me that I can power off the clocks & supply my own external clocks! Doh! So this is something I'll experiment with eventually.
- I'll eventually test the BNC output that I have on this unit when I build a DAC with BNC input.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.