But why would the propagation delay of generated I2S vs. MCK matter? Datasheet (ESS or AKM) does not specify any timing requirements between I2S and MCK. Only timing between I2S signals.
I don't think if anybody really needs so low noise, -133db(A) is fine. Regarding the power dissipation of 9039pro, I tell you that a typical DDR DIM heating isn't enough, I need to add a thermal conductive pad between the PCB and Cosmos housing to get stable work. 9038pro eats even more.. No doubt that the original IPC-compliant TSQFP50P1200X1200X100_HS-65N has overheated a few times ))
I2S interface is a simple state machine which synced by 49.152MHz MCLK on the DAC side. For 32/768 case the SCLK is equal MCLK but delayed for 2x propagation. To be honest, I didn't test yet 768k sampling because I need to migrate with my FW code to the new Comtrue source but I tried 768k with the previous proto with no luck(kinda of double peaks on the FFT instead of single H1). 368k was Ok. The current proto has only 12nS typical(15nS max), let's see how it will work at Fs = 768k.
Sync mode does not mean that MCK and I2S signals need to be synchronized. It only means they are based on the same clock. What matters is the timing relations of I2S signals (BCK-LRCK-SD). These timings are specified in datasheets.
I'll check 768k later, regarding the economy you can see the reason - the trafo is cheaper:
PS: actually, the reason of 768k fail with the previous proto could be in the FW code + windows driver. The current proto has almost 100%
the new FW source from Comtrue which works with another windows driver. However, my current proto has lots of distortions with the new driver, no idea why. The old driver lets play 768k but I see 500Hz instead of 1000Hz on the output.. I see no dual FFT peaks as my old FW does but clean sine 1/2 frequency ))
PS: actually, the reason of 768k fail with the previous proto could be in the FW code + windows driver. The current proto has almost 100%
the new FW source from Comtrue which works with another windows driver. However, my current proto has lots of distortions with the new driver, no idea why. The old driver lets play 768k but I see 500Hz instead of 1000Hz on the output.. I see no dual FFT peaks as my old FW does but clean sine 1/2 frequency ))
Last edited:
Well, as predicted, DR in the dual mono mode DR = 133db(A), THD+N -126db@1kHz, and that is a bit disappointing. 10kHz H3 become worse, -125db.
Yes, much cheaper compared to the MAX1443x/MAX2216x I use but with diy stuff economy is not a top priority. One possible problem with your setup is that part-to-part skew is much higher than channel-to-channel skew. So separating I2S signals to 2 isolators may cause unexpected timing issues.
Well, I used to think so too. And with AKM converters it is stated in the datasheets that the phase of the MCLK is not important. E.g., from the AK4490 datasheet:"MCLK should be synchronized with LRCK but the phase is not critical."
But it seems like that is not necessarily true with at least some of the ESS converters!
right, I didn't find any comments about the sync mode in the ES9039Q2M.pdf at all. My protos usually not too neat after massive rework was required after tests. For instance, this is the proto where I tested 150Mb/S ISOs.
I re-tested my AK4493 and ES9039Q2M (sync mode) dacs. MCK phase did not matter for either so results were the same if MCK was passed through isolator or fed directly to MCU. What mattered most with both dacs was the timing between BCK and LRCK. By tuning the series termination resistors on both lines I got various results: correct data, garbage, correct data but with swapped channels, correct data but on both channels. AK4493 seemed more lax but ES9039Q2M is very picky at 768k/705k6.
I just received the new ComTrue 7602 controller eval board and 100 parts for fool around with.
Why not just isolate at the USB with AD ADuM4166 into the ComTrue and forget isolating at the I2S level. I used the NVE parts for years isolating the XMOS from the DAC chip and they always had too much jitter especially with 384/768. The Maxim parts seemed a bit better. But the bigger problem with the XMOS was it's switching noise and the jitter since this is an IO processor.
The ComTrue is a state machine which means less issues with jitter compared to the XMOS and lower overall noise. Draw back is you can't diddle with the software to make the HOST to DEVICE connection better.
In regards to the ES9038 pro vs Q2M I agree. I think the big problem with the pro is the heat. Maybe why they came out with the ES9039 series. It would be interesting to compare the Pro and Q2M versions of each.
From doing a bit of FPGA work on the ESS parts the MCLK that is received would probably go right into a PLL and upped 8 times or more and then sample the incoming I2S SCLK input that many times to find the best sample of DATA. This is typically how they lower jitter, though I do see they are on version iV now on the ES9039 parts what ever that means.
Another thing to consider is this... why 384/768? I mean nothing is recorded there, the heat generated and the clocking is not as good so why do that. I support like 38 artist right now with the other side of my company. They ask all the time and I tell them record at 24/88.2 it's the best place to be right now. So I can see that you may want to upsample to 176.4 or something like that just remember even upsampling is ok, odd i.e. 44.1->192 is really bad math.
Thanks,
Gordon
Why not just isolate at the USB with AD ADuM4166 into the ComTrue and forget isolating at the I2S level. I used the NVE parts for years isolating the XMOS from the DAC chip and they always had too much jitter especially with 384/768. The Maxim parts seemed a bit better. But the bigger problem with the XMOS was it's switching noise and the jitter since this is an IO processor.
The ComTrue is a state machine which means less issues with jitter compared to the XMOS and lower overall noise. Draw back is you can't diddle with the software to make the HOST to DEVICE connection better.
In regards to the ES9038 pro vs Q2M I agree. I think the big problem with the pro is the heat. Maybe why they came out with the ES9039 series. It would be interesting to compare the Pro and Q2M versions of each.
From doing a bit of FPGA work on the ESS parts the MCLK that is received would probably go right into a PLL and upped 8 times or more and then sample the incoming I2S SCLK input that many times to find the best sample of DATA. This is typically how they lower jitter, though I do see they are on version iV now on the ES9039 parts what ever that means.
Another thing to consider is this... why 384/768? I mean nothing is recorded there, the heat generated and the clocking is not as good so why do that. I support like 38 artist right now with the other side of my company. They ask all the time and I tell them record at 24/88.2 it's the best place to be right now. So I can see that you may want to upsample to 176.4 or something like that just remember even upsampling is ok, odd i.e. 44.1->192 is really bad math.
Thanks,
Gordon
I agree that 384k and especially 768k is not very useful for PCM recordings and most DACs don't work well at 384k/768k. However DSD is a different story as DCLK of DSD256 and DSD512 is the same as BCLK in 384k/786k but IME ES9038Q2M and ES9039Q2M actually perform better with DSD input. Regarding timings it seems that DSD timings are more relaxed than I2S timings so even sync mode works better.
Two problems with that thinking...
1) ESS converts DSD to their internal processing before sending it out to their PWM stage.
2) The amount of USB errors increase so much with everything I have ever tested over 384. I have 2 procotol analyzers and a full Tektronix USB lab with differential probe. While it doesn't count the errors I can see them fly by. One of the reasons DoP doesn't really work well above 384 and even in some cases at 352.8.
Remember a frame in USB like Ethernet trains on the receiving preamble and then uses that PLL generated clock to clock in the received packet. The larger the packet is the more errors there is. USB audio is not error correcting.
1) ESS converts DSD to their internal processing before sending it out to their PWM stage.
2) The amount of USB errors increase so much with everything I have ever tested over 384. I have 2 procotol analyzers and a full Tektronix USB lab with differential probe. While it doesn't count the errors I can see them fly by. One of the reasons DoP doesn't really work well above 384 and even in some cases at 352.8.
Remember a frame in USB like Ethernet trains on the receiving preamble and then uses that PLL generated clock to clock in the received packet. The larger the packet is the more errors there is. USB audio is not error correcting.
Your 1st problem is not a real problem looking at the results. Attached is ES9038Q2M 60Hz with PCM vs DoP64. With ES9039Q2M results are similar.
Regarding your 2nd problem I've tested my USBtoI2S STM32F7/H7 boards to be bit-perfect at upto 768k/32 in digital loopback (I2S out to I2S in). Also IME DoP256 works without issues in Win10. Same with native DSD256 & DSD512 in Linux.
Attachments
Wavelength, I never heard about 7602, and Comtrue didn't mention that in emails, the latest one I got last week. Also, no any info on their www.