E1DA Cosmos ADC

[phofman]

Yes, the best is to ask John directly.

 

[pkane]

Yes, the best is to ask John directly.

Yes, I tagged him in my message, thanks!

 

[phofman]

To clarify - my "yes" was to your tagging John, not yes to your question. I know next to nothing about core audio

 

[staticV3]

@phofman Thank you so much for making REW even better.
One issue I've come across with Java EXCL:
Using it, I can sample my ADC at up to 192kHz. If I try 384kHz, I get this:


384k Fs works fine using the ADC's native ASIO interface as well as with FlexASIO with driver type set to WMD-KS.

 

[pkane]

ADI-2 Pro FS @768k with Cosmos ADC @768k, both using ASIO:

Zoomed in on the modulator noise:

Recording at 705.6k (ASIO) doesn't seem to work right (regardless of what rate I use at the output):

 

[JohnPM]

Is there any chance of supporting more than 192k under MacOS (@JohnPM)? I can see all the sample rates up to 768k in MIDI Setup app, but inside REW, I get only up to 192k:

Last time I tried higher rates on macOS there were frequent dropouts. It was some while ago though, and on a very old mac mini, so I'll see if higher rates work any better now.

 

[pkane]

Last time I tried higher rates on macOS there were frequent dropouts. It was some while ago though, and on a very old mac mini, so I'll see if higher rates work any better now.

Thanks, John, that'd be great if you could get these rates working on a Mac.

 

[pma]

These spectrum measurements >50kHz are prone to interference "forest" lines, because CMR of balanced input stages quickly deteriorates at higher frequencies and ground CMV currents or capacitive CMV currents are transformed into differential voltage. I would be careful when making any conclusions from such measurements.

 

[pkane]

These spectrum measurements >50kHz are prone to interference "forest" lines, because CMR of balanced input stages quickly deteriorates at higher frequencies and ground CMV currents or capacitive CMV currents are transformed into differential voltage. I would be careful when making any conclusions from such measurements.

It would be hard to explain then, why the interference looks very much the same across two completely independent measurements, one done by Ivan, the other, by me, using very different equipment, measurement software and event different geo locations and on different days

 

[pma]

It would be hard to explain then, why the interference looks very much the same across two completely independent measurements, one done by Ivan, the other, by me, using very different equipment, measurement software and event different geo locations and on different days

I would say it is because of the E1DA ADC input stage CMR (resistor matching). I get considerably better suppression of HF CMV when I put Texas Instruments OPA1622EVM board in front of the E1DA ADC. You may try the test with +In and -In wires of the input measuring ADC cable shorted and connected to the ground (COM) of the DAC - the record should be clean.

 

[pkane]

I would say it is because of the E1DA ADC input stage CMR (resistor matching). I get considerably better suppression of HF CMV when I put Texas Instruments OPA1622EVM board in front of the E1DA ADC. You may try the test with +In and -In wires of the input measuring ADC cable shorted and connected to the ground (COM) of the DAC - the record should be clean.

Here's another test. I'm feeding a -150dB sine wave signal into the same set-up I used to measure above, same interconnects, same config, same everything. The only thing that's changed is the level of the generated sine wave. This is the result:

Oh, and with shorted ADC inputs:

 

[JohnPM]

Thanks, John, that'd be great if you could get these rates working on a Mac.

768 kHz seems to work on a 2020 M1 mac mini, so I'll allow rates up to 1536 kHz for the next build. Note that the desired rate also needs to be set in Audio Midi Setup.

 

[KSTR]

It would be hard to explain then, why the interference looks very much the same across two completely independent measurements, one done by Ivan, the other, by me, using very different equipment, measurement software and event different geo locations and on different days

Doesn't look real to me.
This is the Pro FS R (AK4493) in XLR loopback (+19dBu ref.levels):

While the noise shaping in the AK5574 ADC is significant and might hide some components above ~100k we can see that the "forest of needles" around 100kHz that you show is not present here. I seem to remember having done the same measurements with massive time-domain averaging to drop the noise floor by at least 20dB and it still was rather clean up there, no way as noisy as what you showed.

 

[pkane]

Doesn't look real to me.
This is the Pro FS R (AK4493) in XLR loopback (+19dBu ref.levels):

View attachment 236381
While the noise shaping in the AK5574 ADC is significant and might hide some components above ~100k we can see that the "forest of needles" around 100kHz that you show is not present here. I seem to remember having done the same measurements with massive time-domain averaging to drop the noise floor by at least 20dB and it still was rather clean up there, no way as noisy as what you showed.

Are you, like Pavel, ignoring that Ivan measured the same thing without ADi-2? this is only with the newly enabled 768k mode on the ADC and occurs in the Cosmos ADC, so yes, it’s not “real”

 

[KSTR]

@pkane,
Oops, sorry, guilty as charged ;-)

 

[pma]

Are you, like Pavel, ignoring that Ivan measured the same thing without ADi-2?

Well, yes and no. The key factor is that the E1DA Cosmos ADC is somewhat sensitive to ground current, which quite easily makes interfering spectrum spikes. This is probably a PCB design issue, somewhere there is a shared ground and ground current is then converted to the spurious voltage.

This is the simple test setup:

Input of the ADC is shorted, as you can see the XLR jumper connecting all 3 pins of the connector. Now, 2 measurements are performed, 1st without the copper wire loop, 2nd with the copper wire loop connected to the body of the USB connector where mouse is connected.

1st measurement, no loop

we can see nicely clean noise bottom


2nd measurement, with a small loop to USB2 body via a short copper wire

Please see some spurious spikes, even when the loop has quite small area. The ground current is converted to measured voltage. This gets much worse in a real measurement of a power amplifier. DAC must be on USB isolator, to reduce this effect. To neglect the effect, we would need to use a fiber optic interface for USB link.

 

[phofman]

@phofman Thank you so much for making REW even better.
One issue I've come across with Java EXCL:
Using it, I can sample my ADC at up to 192kHz. If I try 384kHz, I get this:
View attachment 236334

384k Fs works fine using the ADC's native ASIO interface as well as with FlexASIO with driver type set to WMD-KS.

I wonder if other Cosmos users had the same problem. If it still persists, you can enable debug mode in the DLL and we can take a look at the logs (details in https://www.avnirvana.com/threads/v5-20-10-early-access.10787/page-5#post-82326 ). But the problem does not make much sense at first sight because KS and WE should use the same driver.

 

[audio1234]

trl, better to use the Windows ADC Volume slider to control that because Windows will send UAC2 commands at every start of the PC, and the Tweak setting will be overridden.
audio1234, I can make the next batch of Cosmos ADC with CT7601PR but not sure if it's really needed. Look, CT7601CR makes some extra wide-band noise at 768k(FFT spikes at >200k will be the same, it is about ES9822 noise-shaper) but who needs to measure the noise level higher than 20k, or Ok, 100k? Harmonics look the same, whatever, 768 or 384k, so you can investigate THD at higher frequencies. CT7601PR is more expensive, actually, I don't know how much that is today but for my 9038D6K DAC I buying opamps for 5x prices i.e. the silicon crisis is still here. Hence, Cosmos ADC with CT7601PR would be more expensive but practically will not give you anything else.
phofman, I didn't try that REW version yet.

Thx for the explanation. So the wide band noise in the 768k mode are only appearing above 200kHz (which is totally irrelevant for audible purpose) and are actually created by the ADC Chip itself and not the USB bridge. The USB Bridge should just convert I2S Stream into a nice USB Stream and if it would be too slow maybe packet losses will occur but it should not have an impact within the Analog domain or within the conversion process inside the ADC chip.

So the new firmware is actually doing something like this (i know its probably not correct and complete):

1. Initializing the CT7601CR into the previously hidden 768khz mode for the USB bridge
2. Setting the ADC Chip into the fully supported 768khz mode
3. Announcing the new 768k modes within the USB Device Descriptor

Sorry for being so pointy with that , I just wanna make sure to understand this topic completely, because I might order a second unit. So actually it should be nearly irrelevant if we use the CT7601CR or CT7601PR in the Cosmos ADC if we remain in the audible frequency range, correct? Maybe some of us were the CT7601CR will not perform correctly in the 768k mode because it was not selected as PR in the production version (due to limitations in the actual silicon) but in this case the experienced failures should be really noticeable and more in the Digital (USB) Domain. I just wanna be sure that I might get foolish measurements due to this high speed mode without noticing it.

many greetings from Germany! (I am also looking for your Scaler)

 

[IVX]

audio1234, 768k noise is rising wide=full band, and you can notice that at the THD+N 20-20k BW result 10db difference vs 384k. The problem is CT7601CR which is too slow for a flawless 768k operation. The same result I got with CT7601SR which intended for up to 192k but works at 384k + extra noise and doesn't work at 768k.

 

[Joachim Herbert]

Anybody using CosmosADC with Virtins Multiinstrument? Any input on driver and setup appreciated.