An STM32H7 based Audio Analyser (or so it begins...)

[betocool]

Hey all,

I wanted to share this project with you and ask for advice as well.

First of all, feel free to ask questions or use any resources here presented as you wish, as well as suggesting improvements.

I'm a bit of an audio buff. Not the "virgins in the moonlight" and "golden Ethernet cables" guy, more of a "I want it to measure and sound good" sort of person. I had a chance to work eons ago with an Audio Precision unit at Uni, and it was such a pleasure. However, I didn't like:

• The price
• The fact that it's only windows
• Some proprietary PC - unit interface

I used it mainly to see frequency response on DSP's transfer functions and just fun really.

Years later I bought the QA200 (I guess that was the name), it was a cheap chinese Audio Analyser which worked Ok but it required some .NET BS framework installs, the USB port protocol was proprietary and I could not get it to run on Linux either. By the way, I'm not against Windows, happy to use it at work, but my choice is Linux at home just because after 10+ years I got very used to it. I sold that unit a year or so later after I measured what I wanted to measure (I think it was the output of a Headphone amp and some OpAmp things).

For the last 3 or so years (I move slow) I've been working on an Audio Analyser myself. Requirements:

• STM32 based
• Linux and Windows compatible
• Ethernet IF to the PC (open and easy)
• Have a simple UI that I can expand

The motivation for the above was also that Ethernet is electrically decoupled from the PC (unlike USB). And I get around with LWIP. Plus it's fast. And no drivers required.

I purchased an STM32H7 board (400MHz!) when they first came out 2017 or so with the idea of using it (still am), not knowing it was going to be a PAIN to set up compared to the F7 or F4. But I managed. I had some PCM1793 (DAC) and PCM1802 (ADC) chips at hand (still have) on boards, and I managed to wire all together. Surprisingly enough, after a lot of swearing and sweating, it all worked! I was getting audio data on my PC.

Later I decided to "update" everything to an OS, using FreeRTOS. Also very frustrating experience, especially since STM32 decided to update their libraries and neglected to mention some direction bit that had to be set on the I2S transfer, let alone the bloody MPU issues. But.... I managed yet again!

In the meantime a PCB to be mounted on the STM32H7 Nucleo board was on the way, I purchased all components for 2, built only one, and came across a few hardware bugs that I fixed by removing components and re-wiring OpAmps (the rookie mistake, swapped + and -). But I got it to work!



So there's the hardware mounted on the Nucleo H7, all powered by an 10V AC wall wart (all the power is converted on the board) and connected to my desktop switch.

This is an updated schematic (differs from the actual board, some power supplies have been removed, +/- have been corrected on the OpAmp).

 Arduino_codec.pdf (127.13 kB - downloaded 109 times.)

Basic theory of operation so far is:

• Receive a TCP request from the client (he who wants data)
• Generate a pulsed sine signal of a certain frequency and amplitude and send it out on the DAC
• Start grabbing audio on the ADC. Both actions are timed to be able to sync the data
• Start sending the audio input over the TCP stream
• Stop the connection when the requested data amount has been sent
• [Wait for another request/li]
  

The client is written in Python using PyQt and the plots are using pyqtgraph. This combination seems to be very fast and good for plotting. All FFTs and calcs are done using the python script.

Here's a screenshot of a single synced stereo channel (You can't see the left channel on the bottom graph because it's behind the red, but you can see the tiny differences on the frequency spectrum)



Unfortunately most of the options don't yet work, I'm still working on this. Good news though, I managed to receive and calculate 32K FFT's at 96KHz. It takes a while, but the level of detail is great. Ah, and yes, I still need to add the FFT length options .

I'm working now on the rev. B of the PCB, but I'm a bit unsure how to split the power rails. I need +/-12V for the output signal, so that's a must. Do I just remove those tiny components and build a separate +/-12V power supply? My tendency is to go with the latter. The ADC/DAC 5V supply needs to be derived from the +12V with a linear converter, don't want any switching noise in there...
Do I power the 3V3 and 5VD from the bottom board, needing then an additional 5V supply for the uC? Or do I derive all from the +12V rail?

Not sure how to proceed, your opinions are welcome.

Ok, gotta go prepare dinner, but I'm happy to answer more questions.

Cheers,

Alberto

[cncjerry]

I, like you, bought I think every stm32 board that came out a few years ago because the were dirt cheap, fast, functional, with integrated displays on many, etc.  The one I used for my ICOM rotary dial has a display like a cell phone.  I'd be interested in taking a look at what you are developing.  I have an HP audio analyzer.  You need the external ADCs and DACs to get close to that performance.  The oscillator used as a source. is critical as well.  Lots about a DIY analog analyzer is on Diyaudio. 

I think instead of running an FFT you want to control the source frequency and amplitude and then measure the input and output the DUT.   FFT is nice for a quick plot but jn order to measure the very low distortion numbers you really need to filter and measure that frquency amplitude precisely, at least that's my thinking.   
 
I hope it work out and you get some results to share.

Jerry

[moffy]

Nicely done, there is a lot of work in what you have accomplished. I assume that the data you receive and transmit to the PC is burst mode only i.e. you couldn't record a, say song, continuously? I have one of the Nucleo STM32H7 boards, but found, if I remember correctly, that the USB port was Full Speed only, because the High Speed port was occupied by the Ethernet port.(I hope that is correct) I also had a lot of issues getting some of the USB code examples to work, I finally gave up in frustration and moved on to the NXP iMXRT1020 etc. processors. So you have my admiration for succeeding and persevering.
I guess it makes sense to derive everything from the +12v, as long as you don't have to dissipate too much current/power through the +5v and +3.3v regulators. How does the Nucleo get its power? 

[betocool]

Actually, the tool is capable of recording continuously into a PC, that is, I have a test python script that opens the connection to the micro and the micro starts streaming audio into the PC. No issues that I've detected. The script writes the raw data to file. I need to convert it to WAV still or add the correct headers.

I have a bunch of LP, records (those black old round disc shaped things) that I convert to digital for convenience (car, walkman, etc), and I was planning to use this, just haven't built a good enough case or enclosure around.

I'm not a fan of USB in general, you need specific drivers for specific applications and they are a pain to implement both on the IC and on the PC side. That's why I went with Ethernet. Additionally, the H7 introduces the MPU (Memory Protection Unit) and a different cache architecture than all the F series, and that was poorly documented at the beginning (2018 or so). It's way better now.

In case you want to get the settings right for doing Ethernet on the H7 I wrote a "how to" in case I forget in the future (I tend to forget!). https://github.com/betocool-prog/h7_lwip_freertos. Works only on the H7 Nucleo boards.

Cheers,

Alberto

[moffy]

Very nice that it is continuous, do you know what a realistic bandwidth limit is? i.e. stereo in and out at 96k?
With regard to the USB drivers, for the NXP micro's, the devices I use appear as a USB Audio Class 2.0 device so no specific drivers are required.
Wow, your github has a lot of detail about getting the ethernet working. Any plans on githubbing your current code?

[betocool]

Here you go, it's a bit messy and it's more for me to keep track of what I'm doing at the moment.
https://github.com/betocool-prog/Audio_Analyser_FW_OS

The "python" folder has the application. You need to have the protobuf, PyQT5 and pyqtgraph libraries installed.
The firmware is the root folder, for the  STM32H7 board.
"protos" folder contains the definition of the protocol buffers, that's how I do the request or set configuration commands. TCP is used for audio data, UDP for control and commands.
Every thing runs from the "tasks" folders, with what I hope are suitable names and modules.

The Kicad project is here. But again, it has had some changes and it's not finished unfortunately. I'm seriously considering a 5V input and a +12/-12V input and deal with the power supply externally. That will make this board much more compact. I might even add a 12.288MHz (or 24.576 MHz) oscillator...
https://github.com/betocool-prog/Arduino_codec

Can't tell you a realistic limit, but 96Khz @ 32bits (expanded from 24) stereo is 6.144Mbit/s. I'm sure you could go easy 10Mbit/s, perhaps even 192Khz 32bit (12Mbit/s), but I haven't tried that yet. What I can tell you is that it's not even close to getting to the limits in terms of what it can do.

If you're interested in trying this out, I can send you a bare PCB, only thing is you'll have to populate it yourself and do some funky wiring to get the opamp to work... Otherwise if you end up having a look at the code and something's not clear, feel free to ask.

Cheers,

Alberto

[moffy]

Thanks very much for the info and setting up the site! I will definitely have a look at it, and will probably check in from time to time to see how things progress. The nice thing about using ethernet is that you can transmit over long distances without problems.
Thanks also for the offer of the board, I already have a Focusrite Clarett 2 Pre which has superb performance, but the hacker in me is tempted because I already have the Nucleo board and love to experiment. I'll let you know. Congrats for now.

[moffy]

I will decline your kind offer of a free board as I don't intend to go back to the STM32 processors, so building it for me would only be a curiosity, which I would then store away. Your code though will be interesting, as I can see reasons to use the ethernet port rather than the USB at times. Unfortunately neither of the links seem to work, I get a 404 error, but I can see your page about the FreeRTOS and LWIP. Cheers.

[betocool]

moffy, I had the repos as private! I changed them to public, if you're still interested, those links should work now.

I personally prefer Ethernet over USB, although the TCP learning curve can be a bit steep, once you got it, it works on most computer platforms.

Cheers,

Alberto

[moffy]

Thanks very much, I'll look at them straight away.

[MasterT]

This is my H7 distortion analyser
Recently I discovered that $4(CAD)   ADC from microchip MCP3561R has much better SNR+THD performance than ANY audio
SD ADC I have ever tested ( PCM 18XX, CS53XX, PCM4202, WM87XX etc.)

 My decision was to process data on micro - not too transfer anywhere and not spend a life time to debug interface itself, instead of coding just SA part.

[betocool]

Indeed that one has better SNR and distortion values on a first look than the components I used. What DAC are you using and what is the interface to the H7? What is your sampling frequency?

Reason why I went Python on the graphical side is that it's easier for me to whip up something quickly in PyQT as a graph than using and troubleshooting the on board LCD screens.

I probably could process data on the micro and then send both time and frequency information over the TCP stream, at the moment I'm happy to offload the task to the PC. Ok, troubleshooting was a bit of a pain, but that was due to H7's having a different MPU and DMA architecture than all previous chips.

[moffy]

I prefer for an ADC that covers the audio range and above the ADS8900B, it extends up to 1MSPS, has a noise floor between -140 to -150 db and a THD of -125db at 2kHz while sampling at 1MSPS. But it is a LOT more expensive.
I also like the ADS127L01, 24bit, 512ksps, 115db SNR and -129db THD, cheaper than the ADS8900B but still more expensive than the MCP3561R.

[MasterT]

I see. I went technically same route, tweaking DMA-SPI than MPU. But more than that, my first SA was based on AD7988. After I successfully interface ADC to H7, I noticed two issues:

1. false freq. spikes on the spectrum chart;
2. phase noise was unusually high.

After long discussion on the ST support board, I was told that H7 is using 8 MHz -> external clock to mail PLL from ST-Link. But ST-Link generates this clock out of RC internal oscillator (64 MHz or so). Dumb stupid decision, but they do it on purpose of compatibility with arduino IDE 8 MHz. ST Link has external crystal 25 MHz that is not possible to divide to 8 sharp. Now, this brought to an option (during upgrade procedure of the St Link) use 8.33 MHz from crystal or 8 MHz out of RC.
A couple years ago I had no this option, so I modernise nucleo - H7 re-routing some jumpers I brought 50 MHz from Ethernet chip.
So, problem 2 was solved.

Problem 1 turns out to be from Ethernet output driver. I was sure if I 'm not using Ethernet any where in a code, and not explicitly authorise this bitch to run it's stays in sleep. I was wrong. Nucleo developer made a mistake, so even Ethernet itself is not running, it's output driver does. 100 MHz 100 mA or more aggressive RF transmitter. This what you least want anywhere in the SA project.

I removed L inductor that powers up Ethernet, and eradicate all sources of noise.

My sine wave 2 kHz & 200 Hz source is not a DAC based, but very high Q (1000-2000) selective filter, tween-T and LM49721 (200 Hz -> 10 KHz) or OPA2365 (2 kHz -> 100 kHz). Have no means to verify THD level exactly, but tests using different ADC indicate signal is better than -130 dB THD.

[MasterT]

I prefer for an ADC that covers the audio range and above the ADS8900B, it extends up to 1MSPS, has a noise floor between -140 to -150 db and a THD of -125db at 2kHz while sampling at 1MSPS. But it is a LOT more expensive.
I also like the ADS127L01, 24bit, 512ksps, 115db SNR and -129db THD, cheaper than the ADS8900B but still more expensive than the MCP3561R.

I 'm watching thread here https://www.eevblog.com/forum/metrology/ad4630-24-new-sar-adc-from-analog-devices/new/?topicseen#new
 Demo board $200 on analog, way above my budget.....  But I have AD7693, close to -120 dB at 10 kHz, and slightly worse AD7982 (-115).

BTW, I have on-line code for MCP3561R https://drive.google.com/file/d/1DzUVrgU4mdnkKblT_ltabVeJS97TnC5g/view?usp=sharing  Not latest version, though. Lately, I switched to SPI arduino library for compatibility with MAX11270 - same code guaranteed same results expectation. If not, than difference in the hardware performance

[moffy]

Wow the AD4630 is a really nice part, but expensive and BGA package, pity.