Go Back   Home > Forums > >

Equipment & Tools From test equipment to hand tools

ADCs and DACs for audio instrumentation applications
ADCs and DACs for audio instrumentation applications
Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools
Old 13th January 2020, 01:39 AM   #51
syn08 is offline syn08  Canada
diyAudio Member
 
syn08's Avatar
 
Join Date: Aug 2005
Location: Toronto
Quote:
Originally Posted by 1audio View Post
What I have come to understand is that those lower frequencies have the least influence on SNR and audibility. I may well be simplifying it since the audio stuff is full of controversy and contention but the industrial stuff tends to be pretty clear.
Not sure about audibility, but certainly the LF phase noise doesn’t contribute much to the jitter. That’s because the jitter is proportional to the square root of twice the phase noise integral, from zero to 2*fo. As such, usually the LF part of the phase noise area has a rather small contribution, in particular for frequencies fo in the tens of MHz, since the phase noise gets flat usually in the tens of KHz.

Last edited by syn08; 13th January 2020 at 01:41 AM.
  Reply With Quote
Old 16th January 2020, 02:57 PM   #52
syn08 is offline syn08  Canada
diyAudio Member
 
syn08's Avatar
 
Join Date: Aug 2005
Location: Toronto
Quote:
Originally Posted by syn08 View Post
Not sure about audibility, but certainly the LF phase noise doesn’t contribute much to the jitter. That’s because the jitter is proportional to the square root of twice the phase noise integral, from zero to 2*fo. As such, usually the LF part of the phase noise area has a rather small contribution, in particular for frequencies fo in the tens of MHz, since the phase noise gets flat usually in the tens of KHz.
Ok, so the ADC clocking works to my satisfaction, using the CDCE913 clock generator. Feeding from a 24.576MHz ultra low jitter oscillator (Crystek CCHD-957-25-24.576) straight dividing by 32...512 for the LRCK (also the sampling clock), using the internal frac PLL to up the frequency by x8, x6, x5, x4, x2 then divide by 4, 8, 16, 32, 64 for the BCLK. All possible combination of 8, 16, 20, 24, 32 bit and 48, 96, 192, 384, 768 KHz sampling are available. A simple logic with a 74LVC04 hex inverter and a 74LVC02 quad NOR creates the CNV pulses (>20nS) on both LRCK edges (for two channels), so that the LTC2378-20 acquires the input and starts the conversion (completes in less than 675nS).

Clocks are clean and nicely synced, see below (32bit@768KHz sampling, 49.152MHz BCLK, I may eventually try a 32bit SAR, not a priority since I'm not expecting anything better compared to the 20bit LTC2378). The LRCK has a phase noise/jitter below what I can quickly and reliable measure and is certainly under 1pS.

Feeding the LTC2378-20 with these signals (CNV, BCLK) renders the target performance (THD<-125dB, SNR>103dB) expected from this SAR ADC.

I wonder if 44.1KHz ADC sampling is required for instrumentation purposes?
Attached Images
File Type: jpg plot0171.jpg (171.2 KB, 344 views)

Last edited by syn08; 16th January 2020 at 03:14 PM.
  Reply With Quote
Old 16th January 2020, 03:52 PM   #53
1audio is online now 1audio  United States
diyAudio Member
 
Join Date: Mar 2004
Location: SF Bay Area
ADCs and DACs for audio instrumentation applications
I would provide for a 44.1 clock chain for several reasons-
1) Some unanticipated backward compatibility requirement
2) I like to measure 48 K devices with 44.1 clocks to ensure there are no hidden synchronous things happening
3) I believe those clocks have an enable pin so its pretty trivial to tie two XO's together and switch between them. No intervening logic required.

Far more important is making sure the clock performance isn't compromised in distributing it to the ADC. The original demo board for the AK5394A had a gate oscillator for the master clock on a shared chip and it had lots of issues. Using an external Crystek oscillator (and some other obvious fixes) got almost 20 dB improvement in spurs and distortion confirming to me how important those details are.
__________________
Demian Martin
Product Design Services
  Reply With Quote
Old 16th January 2020, 04:39 PM   #54
phofman is offline phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
Quote:
Originally Posted by 1audio View Post
2) I like to measure 48 K devices with 44.1 clocks to ensure there are no hidden synchronous things happening
This is a very good point. Analogy - measurements are typically performed at 1kHz which is a major USB frequency.

44.1 is a bit more complicated to transfer over USB than direct multiples of 1kHz, it may take more work on the device firmware if being produced in-house.
  Reply With Quote
Old 16th January 2020, 05:11 PM   #55
syn08 is offline syn08  Canada
diyAudio Member
 
syn08's Avatar
 
Join Date: Aug 2005
Location: Toronto
Quote:
Originally Posted by 1audio View Post
I would provide for a 44.1 clock chain for several reasons-
1) Some unanticipated backward compatibility requirement
2) I like to measure 48 K devices with 44.1 clocks to ensure there are no hidden synchronous things happening
3) I believe those clocks have an enable pin so its pretty trivial to tie two XO's together and switch between them. No intervening logic required.

Far more important is making sure the clock performance isn't compromised in distributing it to the ADC. The original demo board for the AK5394A had a gate oscillator for the master clock on a shared chip and it had lots of issues. Using an external Crystek oscillator (and some other obvious fixes) got almost 20 dB improvement in spurs and distortion confirming to me how important those details are.
Quote:
Originally Posted by phofman View Post
This is a very good point. Analogy - measurements are typically performed at 1kHz which is a major USB frequency.

44.1 is a bit more complicated to transfer over USB than direct multiples of 1kHz, it may take more work on the device firmware if being produced in-house.
Ok, this will need a second frac PLL, not a big deal, there is a CDCE925 with two PLLs, I'll take care of that. The LRCK and BCLK outputs will have to be gated with the main clock generator, also not a big deal. I'll come up with some results soon.
  Reply With Quote
Old 5th February 2020, 05:16 PM   #56
syn08 is offline syn08  Canada
diyAudio Member
 
syn08's Avatar
 
Join Date: Aug 2005
Location: Toronto
Ok, so I have to admit defeat on this topic and put it on the back burner, before even reaching the "project" status.

Recognizing that the current audio ADC chips are the toughest limitation for audio instrumentation purposes, I was looking into industrial grade ADCs and check if they would be more appropriate. I've explored the Analog Devices LTC2378-20 (20bit 1Msps SAR), the TI ADS8900 (20bit 1Msps SAR) and the TI ADS127L01 (24bit sigma delta, 500Kbps). All these chips met or exceeded what I think should be the acceptable limit for audio instrumentation purposes (sampling rate minimum 384KHz, noise floor better than -150dB up to 192KHz, THD better than about -125dB @2KHz and better than -115dB @20KHz, as much as possible independent of the input level, down to the harmonics in the noise floor) so the prospects were initially good. I also explored a few chips for generating a high quality clock tree (AD9508, CDCE913) with great results; 1pS or better jitter was not difficult to get with these modern chips.

Where I failed miserable was in the digital signal processing; I am by no means an professional electronics designer, and much less a professional digital electronics designer, but I am not scared of software/firmware development when/if I get to that; so I though the digital processing will be the least difficult issue to tackle; I couldn't be more wrong.

First, all these industrial grade ADC chips are outputting what the data sheet calls "SPI compatible" serial data. I thought "SPI compatible" means some resemblance to the SPI specification, and it does; the interface is 3 wire or 4 wire with chip select. However, now what? Passing SPI over an USB transport is doable (more about later) but what good would that make? I was not about to write a PC based spectrum analyzer that bypasses the USB 2.0 audio interface, or even less a set of drivers that would convert SPI with the I2S in the target OSs. So it would be more logical to convert SPI to I2S on the ADC side and leave the computer side work to be handled by the ASIO4ALL driver up to the PC application level. That's an much easier win, and it took only a few nights works to implement a SPI to I2S bidirectional bridge, using an Altera/Intel EPM1270 CPLD, even with my rather poor VHDL knowledge. To my surprise, there are more or less critical timing issues buried in the ADC chips data sheets that would not allow any obvious (to me) one-size-fits-all CPLD implementation (but I could be wrong, I don't know) so the VHDL code had to be slightly adjusted for each chip. So "ISP compatible" doesn't really mean "ISP spec compliant"...

Ok, then again, now what? I thought it's time to pass back and forth the I2S data over USB. And here's where the big shock came.

First, the I2S spec elaborated by Phillips in the 90's is low speed (up to 48KHz) only; the eventual extension to 192KHz elaborated by Cirrus (if memory serves) was largely ignored by the industry.

Secondly, the SPI protocol is addressable, including 8bit of command and only 16bit of data, so not a chance in hell to send 20/24bit data in a single frame over USB, a multiple frame approach is needed (which again is not rocket science to implement and could still use the existing USB 1.0 and/or USB 2.0 transport hardware/firmware). But with what impact in performance (except for latency that for instrumentation purposes could be ignored, or at least I think so)?

Third, with two exceptions, I was unable to find any I2S over USB chips that would implement any transport @384KHz or even @192KHz. Everything available from the usual suspects seem to constrained to 48KHz. The notable exceptions I found are XMOS and C-Media chips (I have not explored the Amanero route). Unfortunately, I found no documented way to use XMOS in a USB bidirectional interface (some Chinese boards are claiming such, but I've learned they are not to be trusted) while the C-Media chips belong to the NDA realm; they claim it (@192KHz though) but the data sheet is a joke describing the chip pinout, the SDK is available only under NDA, no development/evaluation board is available for purchase. OTOH, such a bidirectional interface could be clearly implemented (with probably an extensive development effort, though) in a TI TMSxxx, AD Sharc/Blackfin DSP, or a Xilinx FPGA, and perhaps an extra USB interface chip, but at a rather high cost, not to mention that using a general purpose DSP for this task looks like using a cannon to shoot sparrows.

So this chain of ADC SPI<->I2S<->DSP/FPGA<->USB looked much more complex and effort intensive that I was originally assumed and willin to engage into. IMO, this makes Jen's effort to implement the RTX6001 so much more admirable...

For me, perhaps it's time to split this (time permitting) in much smaller sub-projects and tackling the difficulties separately, then eventually combine them into a larger project (if it will get to that). I'll keep you guys updated about any furter progress, but don't hold your breath (not that you really did, so far ).

Sorry for the long rant, I guess all these are old news to those, unlike myself, already skilled in digital audio...
  Reply With Quote
Old 5th February 2020, 05:30 PM   #57
phofman is offline phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
The interface part of the solution is always the very critical issue. USB audio does not need I2S, just the available existing USB audio class 2 firmwares happen to exist for chips with I2S bus. There is no reason a USB-audio firmware could not work with SPI - just probably not available out of the box, would have to be written.
  Reply With Quote
Old 5th February 2020, 06:25 PM   #58
1audio is online now 1audio  United States
diyAudio Member
 
Join Date: Mar 2004
Location: SF Bay Area
ADCs and DACs for audio instrumentation applications
Jen's programmer found the XMOS to be quite challenging to work with. Others have also said the same. Supporting UAC2 would make everything easier but once you are above 192Ksps not much software would understand it anyway. Maybe Virtins, which also supports different protocols.

Its very hard to see an improvement over the performance of the RTX. The AK5394 audio band performance is quite exceptional but it stops at 192 KHz and is officially obsolete. The new audio chips are not as good in several dimensions.

Frex seems to have had some success in SPI (ADC type) to I2S conversion in a logic array. You can look at his implementation and code DIY Analog-to-Digital Converter project.Audio measurements tool Since you are looking down the same path maybe some sync would be good so you aren't dupicating efforts unnecessarily.
__________________
Demian Martin
Product Design Services
  Reply With Quote
Old 5th February 2020, 07:31 PM   #59
syn08 is offline syn08  Canada
diyAudio Member
 
syn08's Avatar
 
Join Date: Aug 2005
Location: Toronto
Quote:
Originally Posted by 1audio View Post
Frex seems to have had some success in SPI (ADC type) to I2S conversion in a logic array.
As I said, SPI to I2S was the easy part: I did it in an Altera EPM1270 (way to big for the job, but that's what I had in hand), with a little VHDL code, using the Quartus II Lite free software.

It's the USB bidirectional path that stinks, as much as the outdated I2S specification, with no update in sight; the trend seems to be "each on his own". A very sad situation IMO, but it reflects the reality: no general interest beyond 48KHz/16bit developed since the Red Book, to justify a chip investment.

The other solution I had in mind was to hack a sound card and expose the internal I2S path to the outside world, then tap into with my own ADC/DAC hardware. But then this would be at best a proof of concept that would ultimately not prove anything beyond what the stand alone ADC setups can't already show.
  Reply With Quote
Old 5th February 2020, 07:36 PM   #60
syn08 is offline syn08  Canada
diyAudio Member
 
syn08's Avatar
 
Join Date: Aug 2005
Location: Toronto
Quote:
Originally Posted by 1audio View Post
Its very hard to see an improvement over the performance of the RTX.
I disagree on this one. An industrial class ADC like the 24bit ADS127L01 would definitely be a net improvement; it would provide an at least 6dB improvement in the THD, with only a minimal SNR trade.
  Reply With Quote

Reply


ADCs and DACs for audio instrumentation applicationsHide this!Advertise here!
Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
FS: Digital Audio ICs - ADCs, DACs, SRCs, other stuff.. len_scanlan Swap Meet 0 29th December 2011 08:40 AM
Fundamental Questions: ADCs, DACs, I2S rsbonini Construction Tips 10 5th August 2011 09:40 PM
M-Audio Delta-44 and instrumentation under Linux suzyj Digital Source 8 27th July 2007 03:43 PM
Audio DACs, Instrumentation DACs. Brian Guralnick Digital Source 10 3rd November 2002 04:56 PM
DSD ADCs and DACs Brett Digital Source 8 14th October 2002 08:59 AM


New To Site? Need Help?

All times are GMT. The time now is 01:31 AM.


Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2021 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 15.00%
vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2021 DragonByte Technologies Ltd.
Copyright ©1999-2021 diyAudio
Wiki