E1DA Cosmos ADC

[misureaudio]

It works with LabVIEW via Comtrue ASIO, too

Work in progress

 

[onlyoneme]

Yes.

Sometimes more often than others. I have much more experience with the ADC Classic, of course.

Did you try to increase ASIO buffers?

 

[IVX]

Did you try to increase ASIO buffers?

probably.. BTW, I see no reason to use anything else but Java EXCL(REW Exclusive WASAPI up to 32/768).

 

[BKDad]

OK, today's update.

This morning, I took the whole setup apart and redid it. Same cables. Now, the glitching seems to be gone. That could mean there was some dirt on a connector somewhere. It could also mean that there is some AC mains disturbance that somehow gets into the audio test system occasionally. Too early to tell. In any case, it all seems to work very well now. Go figure.

Edit: I just tried Ivan's suggestion of using Java EXCL instead of FlexAsio with Windows 10.

Here's the funny thing. I took a screen shot of the Preferences window in REW showing the level indicators for ASIO. Here's what came up:

Now, I changed to Java EXCL. Same screen shot:

OK. But, here is the absolutely incredible part. I restarted REW and selected FlexAsio again. Now, I get the same level indication as I did with Java EXCL previously. I'll stick with Java EXCL.

I'm really not getting this. Software baffles me.

 

[BKDad]

I want to finish off my observations on the new ADCiso that arrived this week.

After finding what appears to be the glitch causing bug in my test setup, I carefully cleaned all the various connectors. I also swapped in a more robust USB cable between the ADCiso and the USB 3.0 hub (!) I now use to connect all the test gear to the computer. Finally, I toggled all the dip-switches on the bottom of the ADCiso a couple times to make certain that they were fully engaged in the right positions to get a FS sensitivity of 2.7 Vrms.

Then, on to the REW settings. I decided that Java EXCL worked best, with a buffer size of 64K. I also changed a setting on REW so that 32 bit data is treated as 24 bit.

So, here is the result.

That's the "Victor" signal generator at 1.88 Vrms output (that's the same level as -0.5 dBFS out of the Topping DACs I use for other testing) to the Scaler set for 0 dB of gain, to the ADCiso. The ADCiso is powered by a linear, regulated wall wart from Jameco. The Scaler is powered by a DC power pack. The test generator is powered by an LiFePO4 battery pack.

The above is with no notch of any kind. Not bad, eh? All the credit should go to Victor, Ivan, and John Mulcahy, the creator of REW. I guess ESS deserves some, too. And the opamp manufacturers.

I hope this helps somebody trying to get their own system working.

Now I'm just awaiting the Cosmos DAC...

 

[BKDad]

Something else...

Remember my unhappy observation about the Topping E50 performance as a test signal source? E50 Whining

Well, I asked about that in the E50 review thread. A fellow by the name of Rantapossu replied. He suggested that I activate L+R in the signal generator panel of REW rather than just use one channel. Look at the difference. This is E50 > Scaler > APU > ADCiso.

That's 17 dB lower for the 3rd harmonic. That's even better than what Amir measured. (I must have a better test set-up )

But, why does it work this way?? Is it a Topping DAC thing or an REW thing? The levels didn't change.

And... Here is what happens with the Second Output Inverted:

Look at the 2nd and the higher frequency even order products.

I tried the same tests with the D10s:

This is obviously academic for actual listening, but for testing it matters. To the eye, anyway.

The Invert Second Output probably says something about the power supply regulation, although that might be crosstalk within the DAC chip, too. But, in two out of two DACs?

OK, you guys are tired of me by now. Back to read only mode.

 

[phofman]

Theoretically Topping can fine-tune the built-in THD compensation curve in the DAC chips for both channels running, and when one of the channels (incl. the analog circuits behind the DAC) produces no signal (i.e. also smaller load on the PSU), the THD compensation becomes suboptimal. Just 2 cents...

 

[phofman]

Also the 1kHz signal may interfer with 1ms USB packet artefacts in the DAC, producing skewed results. It's better to use a slightly different frequency.

 

[IVX]

Theoretically Topping can fine-tune the built-in THD compensation curve in the DAC chips for both channels running, and when one of the channels (incl. the analog circuits behind the DAC) produces no signal (i.e. also smaller load on the PSU), the THD compensation becomes suboptimal. Just 2 cents...

I 100.00% agree, someone too lazy to find the root cause of mutual H3 influence L2R/R2L, and THD was compensated for a mono signal

 

[BKDad]

Theoretically Topping can fine-tune the built-in THD compensation curve in the DAC chips for both channels running, and when one of the channels (incl. the analog circuits behind the DAC) produces no signal (i.e. also smaller load on the PSU), the THD compensation becomes suboptimal. Just 2 cents...

Makes complete sense to me.

 

[Skj]

dear members, i am about to get cosmos adc and apu. is there any guide about the cables polarity and connection from mic to apu and apu to adc ? has anyone used the combo for the live recording ?

 

[Skj]

dear @IVX i have ordered iso version from ali express and would like to use it with two apus for stereo recording from condenser mics. what woul be the appropriate gain setting on apu ? 34 or 60db ? 34db imo may be too low even for at 1.7v setting in adc and 60db may require 4.5v on adc. is there any plan to include 48v phantom power in scaler along with xlr input for mic use ?

 

[Skj]

also kindly guide about the cables from mic to apu and apu to adc for stereo recordings >

 

[Skj]

This is what the Tweak application looks like:
View attachment 158619

While experimenting with the ADC, I noticed a few things regarding the user interface that I think could be improved. Firstly, there is no error indication if settings are changed without first pressing the the "Connect&Read" button or if the ADC has since been unplugged. Secondly, the filter selection would be easier to operate if it simply consisted of four drop-down menus, one for each ADC.

what are the best settings for integrator and filter for recording a live performance through mics and apu ?

 

[Sokel]

Something else...

Remember my unhappy observation about the Topping E50 performance as a test signal source? E50 Whining

Well, I asked about that in the E50 review thread. A fellow by the name of Rantapossu replied. He suggested that I activate L+R in the signal generator panel of REW rather than just use one channel. Look at the difference. This is E50 > Scaler > APU > ADCiso.

View attachment 319243

That's 17 dB lower for the 3rd harmonic. That's even better than what Amir measured. (I must have a better test set-up )

But, why does it work this way?? Is it a Topping DAC thing or an REW thing? The levels didn't change.

And... Here is what happens with the Second Output Inverted:

View attachment 319265

Look at the 2nd and the higher frequency even order products.

I tried the same tests with the D10s:

View attachment 319266

View attachment 319267

This is obviously academic for actual listening, but for testing it matters. To the eye, anyway.

The Invert Second Output probably says something about the power supply regulation, although that might be crosstalk within the DAC chip, too. But, in two out of two DACs?

OK, you guys are tired of me by now. Back to read only mode.

Same thing happens when measuring with E-MU,either loopbacks or other DACs,choosing both channels playback changes the results in REW.
The second channel connect to nothing or not even shorted to the second ADC,that's without saying.
The biggest changes I have seen is low,measuring 20-30-40Hz

 

[IVX]

dear @IVX i have ordered iso version from ali express and would like to use it with two apus for stereo recording from condenser mics. what woul be the appropriate gain setting on apu ? 34 or 60db ? 34db imo may be too low even for at 1.7v setting in adc and 60db may require 4.5v on adc. is there any plan to include 48v phantom power in scaler along with xlr input for mic use ?

34db is close to optimal for my Rode NT1A, which has pretty typical sensitivity for such mics.

 

[Skj]

34db is close to optimal for my Rode NT1A, which has pretty typical sensitivity for such mics.

incidentally i am also planning to use adc with rode nt1 mics. do default filter and integrator settings in adc give best quality recording or we need to tweak through app ?

 

[IVX]

we use the tweak app only to get the lowest possible distortions and noise but actually, you can add some distortion-coloration by the same app.
I didn't think about it before but your question brought me this idea, and I found that reasonable. You can add a huge amount of the second harmonic(typical tube-sound simulation aim) aka "2nd" field in the Cosmos_Tweak app. Pls take a screenshot of that setting before any changes to don't lose my calibration settings.

 

[IVX]

A couple of days ago I noticed that during the calibration Cosmos ADCiso has no green/blue/red LEDs indication, in about 30% of cases.
I decided to retest all Cosmos ADCiso that I prepared to sell and found the same over there 30-40% of units have no LED indication at all, at least until units are cold. In my area right now pretty unusual "cold" days 23-25C, and that may explain why prepared to sell and tested at 27C units are glitching. The fact that no one so far complained about the issue even more surprised me. After couple of days I found the root cause and FW solution to fix the issue. Technically, I know the folk over here may understand what I mean, the I2C isolator chip adds 100nS of delay or 200nS round trip delay, and correctly implemented 100KHz I2C interface has 100.00% zero chance of getting any trouble with that. Even 10x times longer delay can not affect the stability, if.. I2C implemented correctly What happening with the hardware-implemented I2C of CT7601 from Comtrue, when the ADC unit is warm the delay becomes <200nS and I2C works, however, a cold enough unit slightly increases the delay, and CT7601 I2C interface starts to lose acknowledges! Data becomes corrupted and LED's indication doesn't work. Perhaps Comrtue's I2C reads an acknowledge by mixed-up pulse edge, for example, the issue is easily fixable by adding the 47pF capacitor to the SDA line. A +/- few tens of nS are able to turn over so implemented I2C. Of course, I asked Comtrue for help because no one HW I2C register is documented in the supplied datasheet but Comtrue has been silent so far. Finally, I decided to switch I2C to the software mode, Comtrue's source has such a switch but.. that code for sure never tested at all because it had a lot of principal mistakes. So, I debugged of SW I2C and the interface started to work as supposed to be, the only data rate was way too slow 20kHz. Hence, I had to optimize the code, after I'd omitted tonnes of function() called from another function() and this one was called from one more function(), and so on, I got 33kHz of the data rate. Anyhow, after two days I prepared the FW which fixed LEDs indication issue for Cosmos ADCiso. Nobody asked me, I have no idea why ))

 

[BKDad]

A couple of days ago I noticed that during the calibration Cosmos ADCiso has no green/blue/red LEDs indication, in about 30% of cases.
I decided to retest all Cosmos ADCiso that I prepared to sell and found the same over there 30-40% of units have no LED indication at all, at least until units are cold. In my area right now pretty unusual "cold" days 23-25C, and that may explain why prepared to sell and tested at 27C units are glitching. The fact that no one so far complained about the issue even more surprised me. After couple of days I found the root cause and FW solution to fix the issue. Technically, I know the folk over here may understand what I mean, the I2C isolator chip adds 100nS of delay or 200nS round trip delay, and correctly implemented 100KHz I2C interface has 100.00% zero chance of getting any trouble with that. Even 10x times longer delay can not affect the stability, if.. I2C implemented correctly What happening with the hardware-implemented I2C of CT7601 from Comtrue, when the ADC unit is warm the delay becomes <200nS and I2C works, however, a cold enough unit slightly increases the delay, and CT7601 I2C interface starts to lose acknowledges! Data becomes corrupted and LED's indication doesn't work. Perhaps Comrtue's I2C reads an acknowledge by mixed-up pulse edge, for example, the issue is easily fixable by adding the 47pF capacitor to the SDA line. A +/- few tens of nS are able to turn over so implemented I2C. Of course, I asked Comtrue for help because no one HW I2C register is documented in the supplied datasheet but Comtrue has been silent so far. Finally, I decided to switch I2C to the software mode, Comtrue's source has such a switch but.. that code for sure never tested at all because it had a lot of principal mistakes. So, I debugged of SW I2C and the interface started to work as supposed to be, the only data rate was way too slow 20kHz. Hence, I had to optimize the code, after I'd omitted tonnes of function() called from another function() and this one was called from one more function(), and so on, I got 33kHz of the data rate. Anyhow, after two days I prepared the FW which fixed LEDs indication issue for Cosmos ADCiso. Nobody asked me, I have no idea why ))

Does this only affect the LED indication?

Personally, with the very small Cosmos units sitting on the bench top, the LEDs are out of my eye sight line unless I bend down to look. Unless something is wrong, I never check. I should though...