So I have been hard at work trying to get my headphone amplifier finished. One of the design ideas was to send the digital audio in pass-through fashion via the CPU. However the fact that the STM32F072RBT8 cannot generate the exact sampling rates (there is a percent of error) I decided to make it "listen" to the I2S bus instead. This is done in order that I can do stuff, like a level display, or a spectrogram. It also puts to rest, any possible accusations from audiophiles that I am "fiddling" with the audio and there cannot be any jitter whatsoever.
It was not difficult to get the digital audio up and running, however, few appreciate how much work it is for a CPU to do processing on audio. I am presently reading in all 24 bits at 48kHz sampling rate, and right off the bat we are seeing the CPU take strain.
Therefore, there is only one thing to be done, DMA (direct-memory-access) to the rescue. That means, chucking all we receive, into a circular buffer, and processing that at leisure, i.e. computing the FFT for the spectrogram and the dBm for level (VU) display. The DMA has all the necessary logic to hold off the ARM CPU and all that shit that makes my brain hurt trying to think about it. More about my success (or failure) with that in an upcoming blog post.
With DMA it would be then possible to pass-through all the audio, but alas, the STM32F072 cannot generate accurate master clocks (the percentage error is rather high at 192kHz). While I am sure this will not be seen/heard except with insanely expensive Audio Precision test gear, I do not want to even entertain the idea of that- don't want to provide the fuel for audiophile debates which in turn would condemn this project before it even gets a chance in the market.
Interesting times during debugging
Without fancy (aka fucking expensive) test equipment, I needed to get creative to test the interfaces. And I did that, using rudimentary tools. The three applications I used (in conjunction with my PC sound card's OPTICAL OUTPUT) were as follows:
Then, I opened it for editing in WinHEX, and was greeted by the familiar wav file formatting. Using the reference given here I found where the audio samples began and ended hence, the places where I could do stuff.
Using the feature in WinHEX I marked the start and end positions of the audio data, then used the tool provided in the application to fill each sample with 0x61BA03. This is a unique-enough number to be spotted at a glance in the debugger.
Then, the next step was to use something to play that back, preferably in a loop for debugging. I tried a few programs and found they all did something to the audio i.e. dithering or filtering. I then tried VLC and found that it output the file "as-is", well nearly anyway.
I was perplexed because I was still seeing dithering with VLC, then I remembered I set up my STM32F072 to receive 24-bit audio, and when I checked my output setting, it was set to 16-bit mode- DAMN!
After setting it to 24-bit 48kHz, I got the exact data in the .wav file, being streamed into the microcontroller. YAY! This also proves to the snake-oil consumers (aka audiophiles) that VLC is suitable as a reference media player, its properly designed and whatever is in the .wav file is sent to the D/A converters verbatim! I proved it.
So, this opens up an interesting idea or concept. It proves that .wav files can be used to transmit arbitrary data. I found out later that this is indeed how ONKYO do firmware upgrades on their AV receivers. They give the repair shops a CD or .wav file to play back with a regular CD player or VLC on a laptop, and boom- the new firmware is installed that way including updates to DRM and HDCP keys.
So what to do now about the HDM01
Well, as mentioned, we're going to DMA our way into a solution, and then simply sample the data at a slow rate. This is why DSP chips, are still the first choice for signal processing and why A/V receivers have a DSP, typically an Analog SHARC or Blackfin, in conjunction with a master microprocessor.