Winfried, pay attention that PCM4220/4222 have harmonics rising at the levels higher then ~ -20dB.
Even so those are still orders of magnitude better than the limitations of vinyl.
Alex,Vinyl? Yes, sure
my PCM4222 demo board application is to AD convert phono signals to feed them into a DEQX feeding active Speakers. What's your concern?
Greetings,
Winfried
Everything is fine for vinyl, unless you want to make RIAA correction in digital domain - don't do it!
The AK5572 @192KHz sampling rate, same Slave mode (the XMOS is the master), I2S streaming.
Not too bad, the noise floor rises past 50k and never exceeeds -120dBFS. In fact, it is strikingly similar to the TI PCM4222 @1KHz/-60dB (not sure how the PCM4222 is performing at higher frequencies). Distortion numbers are actually a little pessimistic, I would think, but there's not much I could do unless I decide to put everthing on a properly shielded PCB. I find also remarkable that the performance doesn't degrade significantly with frequency and input level.
I would not use the AK5572 for measurements/metrology, but otherwise it appears to me it is an excellent ADC for strict audio applications.
Input opamps are LME49710, 0dBFS=10Vpp.
Not too bad, the noise floor rises past 50k and never exceeeds -120dBFS. In fact, it is strikingly similar to the TI PCM4222 @1KHz/-60dB (not sure how the PCM4222 is performing at higher frequencies). Distortion numbers are actually a little pessimistic, I would think, but there's not much I could do unless I decide to put everthing on a properly shielded PCB. I find also remarkable that the performance doesn't degrade significantly with frequency and input level.
I would not use the AK5572 for measurements/metrology, but otherwise it appears to me it is an excellent ADC for strict audio applications.
Input opamps are LME49710, 0dBFS=10Vpp.
Attachments
Last edited:
Hi syn08,
I have been following this thread "on the side" as I'm currently deeply buried in another project. However, I have noted that you are interested in how SAR ADCs perform in the high frequency region. To this end I (and two more fine programmers) have been investigating the LTC2380-24 at up to 1.536 MHz sampling frequencies.
FYI I have attached a couple of screen dumps of what the LTC2380-24 looks like at various sampling frequencies (inputs shorted & a 12 kHz Viktor oscillator).
I don't consider the 12 kHz measurement to be "final" - I think that altogether the input circuitry was not optimal so I'm quite sure that the ADC is capable of better performance.
All data sampling was carried out in a custom made FPGA setup/program that these two programmers kindly helped make. The spectra was then generated in WaveSpectra which I happened to find out could handle 1.536 MHz files.
FYI during my tests with the LTC2380-24 I have not noticed any significant rise in HF noise. I have also tested the AK5572, however, since I am interested in high frequency sampling (1.536 MHz etc.) I did not do much more with that ADC (I do use it for measurements, though, as it is simpler with I2S).
Cheers,
Jesper
I have been following this thread "on the side" as I'm currently deeply buried in another project. However, I have noted that you are interested in how SAR ADCs perform in the high frequency region. To this end I (and two more fine programmers) have been investigating the LTC2380-24 at up to 1.536 MHz sampling frequencies.
FYI I have attached a couple of screen dumps of what the LTC2380-24 looks like at various sampling frequencies (inputs shorted & a 12 kHz Viktor oscillator).
I don't consider the 12 kHz measurement to be "final" - I think that altogether the input circuitry was not optimal so I'm quite sure that the ADC is capable of better performance.
All data sampling was carried out in a custom made FPGA setup/program that these two programmers kindly helped make. The spectra was then generated in WaveSpectra which I happened to find out could handle 1.536 MHz files.
FYI during my tests with the LTC2380-24 I have not noticed any significant rise in HF noise. I have also tested the AK5572, however, since I am interested in high frequency sampling (1.536 MHz etc.) I did not do much more with that ADC (I do use it for measurements, though, as it is simpler with I2S).
Cheers,
Jesper
Attachments
Last edited:
I got similar results with a number of 20bit SAR ADCs, in particular a LTC2378-20 running at 1MHz, and got for all THD better than -125dB @2KHz (results are buried somewhere in this thread). SPI conversion to I2S was done in a FPGA and the I2S ws fed into my Rohde UPD for evaluation.
Since then, I'm stuck in finding a practical solution for converting the SPI output to I2S without using a separate FPGA; I have no idea how to approach this within an XMOS core. The problem is that essentially the ADC needs to be in Slave mode and while I2S is a streaming protocol, SPI was designed as a burst protocol. There is a bag of tricks to convert, with DMA, buffering, etc... but I still don't feel yet comfortable enough to approach this in the XCORE framework.
Good question, how did you bring your data @1.5MHz sampling into a PC? The Thesycon/Microsoft Wndows 10 USB driver is limited to 192KHz, which I believe is also a realistic limit for USB2, anyway.
I do not have Windows 10, but Win7/32 ans Win7/64 with Thesycon driver works very well at 384 and 768kHz.
USB2 has max isochronous packet size 1024bytes every 125us microframe for one endpoint, that makes 2.7MHz 1ch 24bit. It is possible to use up to three transactions per microframe (i.e. x3 samplerate) but I have tested only one packet per microframe.
Linux handles easily incoming 2.7MHz 24bit 1ch USB audio class 2 over a regular USB2 (from RPi4 gadget), bitperfect (with healthy HW of course), no dropouts, all the way to displaying 8M FFT https://www.diyaudio.com/forums/equ...ort-samplerates-sw-analyzers.html#post6074296 . Copying to/from a USB drive creates much larger data flow, this is just 65Mbps.
IMO it would be a pity not to aim at such speeds when the hardware and software support it today.
Linux handles easily incoming 2.7MHz 24bit 1ch USB audio class 2 over a regular USB2 (from RPi4 gadget), bitperfect (with healthy HW of course), no dropouts, all the way to displaying 8M FFT https://www.diyaudio.com/forums/equ...ort-samplerates-sw-analyzers.html#post6074296 . Copying to/from a USB drive creates much larger data flow, this is just 65Mbps.
IMO it would be a pity not to aim at such speeds when the hardware and software support it today.
Hi altor & syn08,
First I have to say that I am not a programmer (at all!) so I can only say ever so little about what these two programmers did. But what was used was a Zedboard FPGA and the data was then transmitted to the PC via ethernet ("internet cable").
One limitation though was that the programmer who worked with the Zedboard was not able to make it transmit at full bandwidth so at 1.536 MHz the stable transmission time to my memory is relatively short - and one channel mainly. It improves greatly with lower sampling rates.
@altor: Yes, it would appear that Wavespectra handles 1.536 MHz (and maybe even higher - haven't tried it). Fine software - and even for free (many thanks! to the creator)
Before meeting the two programmers (one of whom I understand may be one of the very best FPGA programmers in Denmark - he has e.g. worked on Airbus a380's core systems) I tried to solve this in hardware logic. Comprehensive but I think I succeeded in making a theoretical model for this (inverters, shift registers and a bit more).
However, wouldn't it be possible to implement something similar in a smaller FPGA or CPLD? And transmit via ethernet or another high speed protocol? Please excuse me if I'm being naïve here - as I said I am not a programmer ;-)
Cheers,
Jesper
First I have to say that I am not a programmer (at all!) so I can only say ever so little about what these two programmers did. But what was used was a Zedboard FPGA and the data was then transmitted to the PC via ethernet ("internet cable").
One limitation though was that the programmer who worked with the Zedboard was not able to make it transmit at full bandwidth so at 1.536 MHz the stable transmission time to my memory is relatively short - and one channel mainly. It improves greatly with lower sampling rates.
@altor: Yes, it would appear that Wavespectra handles 1.536 MHz (and maybe even higher - haven't tried it). Fine software - and even for free (many thanks! to the creator)
Before meeting the two programmers (one of whom I understand may be one of the very best FPGA programmers in Denmark - he has e.g. worked on Airbus a380's core systems) I tried to solve this in hardware logic. Comprehensive but I think I succeeded in making a theoretical model for this (inverters, shift registers and a bit more).
However, wouldn't it be possible to implement something similar in a smaller FPGA or CPLD? And transmit via ethernet or another high speed protocol? Please excuse me if I'm being naïve here - as I said I am not a programmer ;-)
FYI I have a rigisystems USBPAL I2S/USB2 card which reliably transfers four channels both ways of 384 kHz (24 bits to my memory).
Cheers,
Jesper
Yes!
But It a pity that the author drops WaveSpectra and WaveGene - many years there are no updates . Also no answer to e-mails
Does it? The XMOS driver page USB Audio Driver Support | XMOS claims 24bit/384k max for the production Thesycon driver ($$$). Up to 8 channels (I think) but for instrumentation that's of little use.
The Windows 10 USB Audio 2.0 supports only 192KHz.
Linux only is not really in scope, something that runs at high speed on Linux only is of no interest to me. I am also not a friend of the Raspberry Pi toys, unless I would ever think to design a full instrument with an embedded spectrum analyzer, display, etc... Won't happen in my lifetime. Reason is, I invested tons of time and effort in Beaglebone, only to see it pretty much abandoned by the community. These things are not built to last more than a fashion cycle, there will be a Cranberry Sigma in a very few years.
I would very much like an Ethernet based solution, somebody posted earlier a link to the Ravenna Network web site, but I'm afraid the development effort largely exceeds what I am able and willing to invest in.
Last edited: