Measuring and adjusting a X-over

part 3 : actual X-over setup


Now we did acquire some dual FFT measurement tool and we did get some practice in measuring.
So it's time to dive into actual system tuning.

First we have to establish some design goals:

I think there will be no doubt that, at first instance, we will go for a flat magnitude response.
Sure, certainly in live audio there is a big preference for sloped responses.
Be it a smiley curve or more seriously a sloped curve towards the sub end. (upwards that is ;)
But imho this is part of a sound engineers 'artistic' input in a same way as EQ-ing a system to his/her preference is.
Other people (with whom I don't always agree :) have called this toning (as opposed to tuning) a system.

A bit more complicated design goal will be to try to achieve an even controlled response off axis as well.
Why?
Not only will there be (paying?) people listening off axis; anywhere you listen to music, in enclosed spaces, there will be acoustics.
So also sound radiated off axis will (at a certain point) reach your (on axis being) ears.

One way to achieve this is by using  the well known Linkwitz-Riley X-over tuning.
Acoustically that is!
So if we would be applying a 24dB LR x-over in the electrical domain doesn't this necessarily give us an acoustic LR behaviour!

A simple trick to see what a desired 24 dB filter would look like in your measurement.
Just connect the output of your X-over to the measurement input, select a desired X-over trace and presto:

Here you have it, 1600 Hz /24 dB X-over LR style as a target trace.
Don't get confused by the out of band nonsense, no coherence there so no viable measurement data. (actually should have faded this, now where's that button in Smaart, hmm)

Now let see if we can take that measurement from that previous 12' horn loaded cabinet and see if we can give it a LR alignment.

Seems reasonable, hein?
Now look closely and you will notice in the bottom corner the soundweb setting:
2800Hz / 12 dB bessel!
Didn't expect that to work out for an acoustic filter of 1600Hz / 24dB?

We can now continu to see if the 1' driver horn will combine in the same way.
Remember I am measuring everything with music so at the same time I am listening if it sounds anywhere near ok.

Again if you try to read the small figures:
2300Hz / 12 dB Bessel!
From the days I still had to do these things by ear I have a real preference for Bessel filters, 25 years later this finally seems to make sense  ;)
(actually I am going to set up this cab with 18 db Bessels but these are not implemented in SW9088)

Final picture?

Microphone is now further away so this is why things start to get more bumpie again.
(for educational purposes unfortunately also in the X-region, no, no, this not a x-over artefact ;)


Are we finished now?
No, but this is a start. We can now start to compare this with different solutions.

Am I anywhere cheating here?
No, but I' am not telling you the whole story (see, this is my business, remember ;)
There is a lot more to be said about adjusting delay, applying EQ at the right places etc etc

You can read in between the lines though...

Using ST32F4 series MCU as a loudspeaker processor

STM32F4

There's a lot of information out there on using MCU's like arduino or more upscale M4 arm-cortex chips like those manufactured by STM as a process controller.
Measuring stuff // Controlling stuff.
Just google STM32F4 and you will find all kind of howto's on how to manage i2c or spi data streams.

We as audio engineers being only interested in i2s are not that lucky.
Don't get confused by i2c versus i2s!
Also there is references for i2c and AD/DA but this will be about analog sensor data. Not Audio!

So, as a future reference, I am going to describe the long and arduous task of getting these things to process audio.
This is not going to be a step by step tutorial: you will need different places to get the required knowledge, but hopefully it will be of use for someone stumbling across.
Bare in mind that the whole process took me about 4 months....


First steps

These are microcontrollers. So they are not running an OS like a raspberry PI. They are also not DSP's, so you can't program them with some third-generation language  like SigmaStudio.
Think bare-metal programming..Think C..
So first thing to do: get some knowledge about (embedded) C coding. Make your first program. The mcu equivalent of 'Hello World' will be a blinking LED.
You could write your code in a text editor, but that will be really die-hard-old-skool. 
Nowadays one uses Integrated Development Environments like a helping hand .
Now do spend some time to pick an IDE that will serve the purpose!
There's quite some free stuff out there, check Platformio or Eclipse based applications.
One warning: these are all community supported and as there isn't a huge audio community active on these platforms you could find that not useful at all!
After unsuccessful trying everything on both Windows and Linux, I finally decide to use a commercial product:

ARM KEIL  microvision

That could cost you some substantial cash, but there is a limited demo version that might just be enough for your purpose.

next to part 2

STM32F4 loudspeaker processing part 2

Second step

So you got that blinking light, maybe you did some stuff with on board sensors or an external control. Nice!
By this time you must have stumbled across the 'library' thing.

At this date I still do not understand the engineering/design philosophy behind the library concept:
Not structured. Not documented. No rules. Not standardized.
And as such a big cause of bugs and conceptual problems.(not only caused by yourself!)

Still you will need them: standing on the shoulders of others.

This alone took one month trial and error to get a working configuration going.
As I am using STM32 microcontrollers I use the HAL (hardware abstraction layer) libraries provided by STM.
More specifically: as these are generated by CubeMX

Next step is to get effluent in using CubeMX to generate the projects base code, then open/import this project in KEIL MdK to add your user code. Maybe get some knowledge about the build in debugging tools. These won't help you a lot in processing audio though, so don't waste to much time there..


Third step

Be brave and connect your first audio board DAC to your MCU board. Maybe you all ready have a DAC on your discovery board as with a STM32F4DISC board.

Now start to understand what is needed to stream i2s data to your DAC. Dig through all those data sheets to learn and find details about the several i2s protocols and how to configure both DAC and MCU. Don't despair! Just familiarize yourself with the keywords and trust the work others have done for you (at least at first).
Apart from the different protocols (use Philips!), the most important concept is: clock signals. To make things more confusing different names are used:

MCK  = CK = master clock
WS = LRCK = word select or LR clock
BCK = SCK = bit clock or serial clock

As audio freaks we do understand sample frequency and bit depth, and how they work out on the different clocks, don't we?
Now generate a sine-wave in code or use some table or whatever and see if you get a peep without cracks and or distortion. If you do consider yourselves lucky and talented. If not learn more about data formats! There is also some good youtube videos by Mutex if you get stuck.
Remember: this is bare metal coding so you have to control everything!
Again 1 more month of struggling: i2s audio data is a signed integer between -1 and 1 (times bithdepth -1) aka two's complement
You will have to control the data format all the time, casting stuff like:

 txBuf =(uint16_t)data_out //filling send buffer with 'typecasted' correct data//

And also be aware of overflow! You can't just multiply or divide your data.
These are helpful:

data_out>>1 //data halved as in 6 dB down in volume//

And hey, here's interesting stuff: ever participated in the floating point versus fixed point debate of audio processing ?? hmmm..


next to part 3