You need really high speed SPI to read the data from SAR ADC.
A microcontroller can't do that.
Take a look at Frex's OSVA
You can find the software at github
Open the project in Quartus and you can get an idea of how to do it.
Usually, F7 costs more, but you do not need exactly F7 - most of the STM32 have I2S/SAI/SPI, even L4.
What may be interesting in F7 - is F723, because it have USB HS internal PHY.
Last edited:
Not planning to write an audio USB interface, I wouldn't know how to do that; the XMOS USB interface is obscured, so there's nothing I could peek at. Or is it? ST delivers source code only for USB 2.0 Audio Class 1.0 compliant (meaning up to 96KHz).
Otherwise, if somebody would do it for USB Audio 3.0, I am sure the XMOS chip would sooner or later vanish from the market. I am still struggling to understand why this ueber exotic XMOS chip architecture was ever seen as appropriate for audio.
If you are talking about what is implemented in CubeMX, as I remember - it is for output only!
And 96kHz - because it is the maximum, which supported driverless UAC1 operation
1) Because some series of XMOS (not all!) was developed to do this.
2) Because Ross developed USB stack and library for their CPU, which supports UAC2.
3) Because except USB tack itself, all other is open source, which give to developers possibility to make their own firmware.
And why would anybody want 1.6MSPS for audio purposes? I certainly don’t...
BTW, have you abandoned your own project of using a SAR ADC? I see it stalled back in January.
Because you mentioned it, I evaluated the LTC2380-24 SAR and it’s inferior (distortion wise) to most of the 20bit SARs available (LTC2378-20, ADS8900), while the noise floor is only a few dB better. Same noise floor as the TI ADS127L01 but significantly better distortions with the TI part (24bit sigma delta) which is down to -128dB @1KHz.
You lost me...
1. What XMOS series are you talking about, and what are the audio specifics? Is this by chance a circular argument?
2. I somehow doubt the XMOS chip architecture was designed to support some low level software (the UAC2 stack), how would that work?
3. The CMEDIA SDK is also now in the public domain, and the source code is much easier to digest, being essentially 8251 based. The whole CMEDIA solution is an 8251 on steroids.
But I would concede that the XMOS software framework is much better layered and makes hacking the code rather easy, without going into the gruelling low level details. XMOS is good to quickly hack something that works (took me 1 hour to integrate with the AK5572 DAC), but very difficult if one wants to go at the bottom of the stack (which is what integrating an ADC SPI interface requires).
It could be argued that XMOS was not intended for the portable/wearable market. The power consumption comes to a performance (or price) penalty, that’s a fact. Problem is, I don’t see the special performance in XMOS.
How large the stand alone audio gadgets market is, probably minuscule today. This falls under a larger debate about the audio appliances market today, XMOS will likely not be the only victim, many high end audio chips will follow (including, but not restricted to, the much praised AK4499).
I came to the same conclusion. Added to that the lack of clear vision in marketing from some interactions with a senior exec of the company. What's odd to me is it was originally touted as a kind of 'Swiss army knife' for implementing complex interfaces in software - as opposed to in hardware (with FPGA). But then they specialized in later generations by the addition of USB hardware...
ESS has a mobile solution to do most of the audio magic the XMOS chip is used for. The ESS is a real non-starter for mobile. Too much power and too big a footprint. Its special abilities are hard to exploit and often can be done other ways. The ESS limitation is that its very entwined with their DAC's and not that flexible.
My bad than
Most STM32 microcontrollers can do easy up to 40-50 MHz SPI if I remember correctly.
Using full bandwith is usefull for the built in averaging that same of the SAR ADC's have. An easy way for lowering the noise floor.
Or with little more code you can do averaging in the FPGA.
Hello,
No, the OSVA project is still in progress and i work hard on it (when i can).
I don't posted much, but it's on the way.
I follow too this thread, and as many others here we would love
for a high sample rate USB audio interface.
I'm not a software man (maybe a little VHDL), but if you are one maybe
you could look the project of SDR-widget from Georges Boudreau.
It is an open source USB audio interface that can handle up to 192kHz
stereo in + out.
I think it would be possible to start with this for a more power-full interface
with higher sample rate support. (That would of course require a more powerfull CPU).
The full project code is available and can be downloaded on Github.
This interface work both on Linux and Windows (even if i would prefer the first).
Maybe that could be a good starting point a take advantage of the great proven work already done ?
Frex
Last edited:
XS1, XS2, XCore200
Some silicons have internal HS PHY, some- ULPI interface to the external PHY.
Many things are implemented inside CM chips in hardware, even on steroids, 40-years old 8-bit 51 chip cannot make all things in software.
Maybe. I never "hacked XMOS software", I used my own, with their USB stack and libraries (however, modified a little bt).
It is just like few (4-6-8-16) of 80-100MHz 32 bit CPU in one case with fast communication between them. Also with the advanced I/O ports with serialization (this can be seen also at other processors), simplified serial protocols implementation (I2S, I2C, SPI, UART).
Last edited:
And that's... uh... required for an audio application?
As somebody else mentioned, XMOS is a solution to a problem that doesn't exist.
Any example where an audio application would exclusively benefit from the XMOS multicore and high speed connectivity architecture?