More on topic, it appears the XE216-512 XMOS chips in TQFP are gone everywhere, with the next delivery in 2022. In FBGA they are available, but that's beyond my capabilities. XU/XUF series is available in TQFP, but these don't have RGMII, meaning no Ethernet support (which I would very much like to have on board). Not sure what to go for...
IMO the MCLK through the isolator will suffer from the added jitter. I dropped the ADC/DAC isolation feature due to this issue plus I have several analog loopbacks from DAC to ADC for automated DAC&ADC level and distortion compensation which the ADC/DAC isolation would further complicate. The isolation if needed will be provided by supporting any additional UAC2-compatible generator with internal USB - analog isolation (and likely providing external inputs for initial distortion/level calibration of the external generator).
What matters is whether or not this additional jitter has any measurable impact on the performance of the converter it is being connected to.
The CM6632A has high levels of random jitter that it adds to the master clock lines. Feeding this into the AK4499 and into a PCM1792A resulted in a raised noise floor in both. The AK4499s was more pronounced but nevertheless the degradation was unacceptable, in my opinion, with either converter.
To get around this I had to feed the master clock directly into the converters and configure the CM6632A for non MCU controlled, isochronous, asynchronous transmission to the PC. When configured as such the direct master clock was synchronous with data out of the CM6632A.
I'd hope that other USB interfaces would be better behaved and keep the master clock they generate cleaner. The CM6632A didn't appear to add in any periodic jitter spikes mind you, just random via the raised noise floor.
The jitter a complete SoC adds is going to be much greater than anything additive an isolator is going to add though. The DAC/ADCs themselves will have an intrinsic amount of jitter they add to the incoming clock too and, given their mixed signal architecture, it's entirely possible that the amount they add is going to be swamp out the amount an appropriately chosen isolator will add.
Naturally you'd have to measure this but it should be very easy to create a bridge over the isolator, effectively nullifying its effect, and seeing if the performance changes at all. With the jitter the CM6632A added, only the noise floor was affected, the distortion was still extremely low.
Putting the master clock oscillator next to the DAC/ADC and then piping it through an isolator to the SoC will give you the lowest jitter at the converter, where it's needed, but it might be overkill.
The CM6632A has high levels of random jitter that it adds to the master clock lines. Feeding this into the AK4499 and into a PCM1792A resulted in a raised noise floor in both. The AK4499s was more pronounced but nevertheless the degradation was unacceptable, in my opinion, with either converter.
To get around this I had to feed the master clock directly into the converters and configure the CM6632A for non MCU controlled, isochronous, asynchronous transmission to the PC. When configured as such the direct master clock was synchronous with data out of the CM6632A.
I'd hope that other USB interfaces would be better behaved and keep the master clock they generate cleaner. The CM6632A didn't appear to add in any periodic jitter spikes mind you, just random via the raised noise floor.
The jitter a complete SoC adds is going to be much greater than anything additive an isolator is going to add though. The DAC/ADCs themselves will have an intrinsic amount of jitter they add to the incoming clock too and, given their mixed signal architecture, it's entirely possible that the amount they add is going to be swamp out the amount an appropriately chosen isolator will add.
Naturally you'd have to measure this but it should be very easy to create a bridge over the isolator, effectively nullifying its effect, and seeing if the performance changes at all. With the jitter the CM6632A added, only the noise floor was affected, the distortion was still extremely low.
Putting the master clock oscillator next to the DAC/ADC and then piping it through an isolator to the SoC will give you the lowest jitter at the converter, where it's needed, but it might be overkill.
Check out the clock generator principle in #956 (and that I just measured above). The whole shtick of this setup is to clean the "dirty" clock generated by the USB controller (XMOS or CM6632) using a reference clock. This is what the CS2100 does, and does well. Then the clean clock gets synced using a D latch and that's that. You can go (like myself) through multiple stages of cleaning, this works pretty well too, although not as efficient as I was expecting, in particular related to the close in phase noise, but then who cares about except the non stationary, time variant, noise modulated fear mongers with golden ears?
>> Putting the master clock oscillator next to the DAC/ADC
Is my main point & beef, may any others too 🙄
Otherwise for measurements any unknown jitter / generation added by any circuit even latched by D-FlipFlop
May I am special on that for any measurements..
Hp
What about the fear mongers with tin ears, but lots of test equipment? One of them trying to flout the rules and pick a fight?
I have no intention to use either SoC generated MCLK passed through the isolator, or PLLed clock from adaptive USB (also passed through the isolator). MCLK will be as close to the ADC/DAC as possible, SAI/DAI in slave mode clocked by the master-related clocks, duplex USB audio in async mode (adaptive mode is a no go for measurement purposes). Also 768kHz 128xFS ESS DAC clock is almost 100MHz.
Given this is the equipment and tools forum one might consider YOU to be the one picking a fight?
The ES9822 has a way of doing this and to synchronise the two chips as far as I remember. Or maybe I'm remembering wrong and you slave one to the other. Either way they are very configurable in that regard. Both would take a direct feed from the local master oscillator anyway and one ADC would control the data flow from the other.
I'm using dual mono in a slave config and they perform fine so far.
Unfortunately ES9822 supports only 32bit TDM frame length in master mode, not 24bits like its sibling ES90xx DACs and other ADCs/DACs. I have yet to test the slave mode but officially the 24bit readout of the serial data is not supported. That makes the bitclock at 768kHz 49MHz even though 36MHz would have been enough (no useful data in LS bits 0 - 7 anyway).
As I had a CS2000 on hand I tried this between the CM6632A and AK4499 as a potential solution. It helped a little but not by much. Whatever the CM6632A was doing the clocks it output the CS2000 wasn't enough.
I ended up using a CDCE18005 for it's ability to handle two clock domains simultaneously, divide them and then buffer whichever domain you wanted in a variety of ways. So currently it feeds the two domains of the 6632A and then separately buffers the master clock for two AK4499s and the dual mono ES9822. A bit overkill perhaps and definitely not a lower power solution but it works.
Calling someone a 'fear monger' was not about equipment. It was intended as personal insult and as an attempt to demean the character of another member. It was not a technical argument at all.
Interesting, the CM6632 must be really bad in this respect, I haven't tried anything but the XMOS + ESS9038PRO in mono mode and the results are excellent.
Interesting, I tried the CDCE chips when I was dealing with the ADC (got a demo board from TI), and didn't cut it for me, the jitter was poor. That was over 6 months ago, perhaps I did something wrong.
Last edited:
And does the slave mode allow 24bit readout? It would spare me a CPLD 32->24bit I2S conversion. A few weeks to learn hard by testing...
A little friendly advice if I may, it could be better for everyone's mental health if you ignore the dogs that habitually snap at your heals, they've been at it so long now they aren't likely to change their behaviour.
As long as both the ADC and the DAC support 32bit why do you need to make everything 24bit? For instrumentation purposes, I don't see this as a constraint, I don't even bother with I2S, everything is left justified
For 32bit, I2S doesn't make any sense, anyway. Altor showed here how to modify the XMOS code to switch to left justified.
If you are forced to adhere to the I2S spec, for compatibility reasons, then this is a different story all together.
For 32bit, I2S doesn't make any sense, anyway. Altor showed here how to modify the XMOS code to switch to left justified.
If you are forced to adhere to the I2S spec, for compatibility reasons, then this is a different story all together.