"Gumby" ER18/10F/OW1 with Raspberry Pi FIR crossover

[Michael P]

I am starting a build thread for some speakers I'm helping my friend (Mike A.) with. He has named them the "Gumbys" since they are designed with a lot of flexibility, though not in the mechanical sense... this will become clear.

The performance goal for these speakers is a smooth and spacious sound, which we aim to achieve with wide (albeit not omnidirectional) directivity.

These speakers are stand mounted 3-ways with the Seas ER18 (7") woofer, Scanspeak 10F/8414 (4") midrange, and Hiquphon OW1 tweeter. These are relatively wideband drivers, so many different crossover frequencies and slopes are possible. I'd speculate that the woofer/mid crossover could be anywhere from 300 Hz to 1 kHz, and the mid/tweeter crossover could be anywhere from 2.5 to 4 kHz. We have done an initial crossover that measures well, but I think Mike would enjoy doing more experimentation based on your suggestions.

The most interesting part of this (at least for Tech Talk) is the crossover. Mike is doing a digital crossover with FIR filters running in real-time on a Raspberry Pi. This allows arbitrary filter responses to be programmed in quickly, and it's a low cost solution. The Raspberry Pi is not used as the source; it has analog and S/PDIF inputs. The Raspberry Pi drives a 6-channel class-D amplifier within the same chassis.

I'll follow up with more posts about the different aspects of the design. Crossover and electronics tweaking is still underway, any advice would be appreciated!

A more thorough photo gallery is under way at the link below.

[Michael P]

Here's a couple photos of the cabinet construction. (I introduced Mike to some of the woodworking techniques, but this is a case of the blind leading the blind.) Believe it or not, the veneer is maple, it's just stained very dark.

The mid is in a 4" PVC pipe. I think this is a handy technique for mounting small mid drivers that need a separate air volume:
- Drill a small hole (to pin the circle jig) at the center of the cutout.
- Use the circle jig to cut the recess for the driver flange, but don't route the through hole yet.
- Flip the baffle over and using a 1/4" straight bit, route a 1/4" deep circular slot.
- Now you can route the through hole from either side.
You might be able to find an endcap for your pipe at the hardware store, but we just plugged it with an MDF disk. Then we glued the pipe into the slot on the back of the baffle.

However, you might ask, aren't there resonance issues with using a pipe as an enclosure? Yes, there are. We did some nearfield measurements. You can see what looks like pipe resonances at multiples of 1 kHz in the red curve (empty pipe). However, adding some polyfill (green curve) and lots of polyfill (blue curve) made them go away. I think this was before break-in, since the Qtc looks suspiciously high. We haven't done a listening comparison, just left the speakers in the "max polyfill" configuration.

[Michael P]

The box is a 25 liter vented enclosure tuned to 37 Hz with a 2" flared port. Maybe this is a little bigger than necessary for the ER18, but why not? (The large internal volume is achieved by making the cabinet relatively deep: 15", I think). The port is mounted on the rear, near the top so it doesn't catch the rear wave from the woofer. There's a wad of polyfill behind the woofer. I think we left the port taped together internally so its length could be adjusted.

Here's the Unibox sim. It looks like this could get up to around 102 dB at 1 meter in the passband (these capabilities haven't been tested yet).

[ani_101]

nice thread and build - those are really nice drivers.. I am interested in the FIR filters with the Pi. Would you be posting more info and details on it?

[Michael P]

The most distinctive feature of this project is the crossover, which can be programmed for any frequency response. More choices are great, but can also create more problems... I'll start with the measurements.

Mike A. measured the responses of each driver in the box with a UMM-6 microphone and REW. These are shown in the first plot (ER18 in blue, 10F in green, OW1 in red). You can see that there is a lot of overlap to work with, with the ER18 breakup at 4 kHz and the 10F extending beyond 10 kHz. The impulse responses are only clean out to ~3 ms in the initial setup, which means we don't have much information below 500 Hz. This has led to a certain amount of guesswork for the mid/woofer crossover. I have a bunch of foam squares that I put out (mostly on the floor) to get better impulse responses, but Mike hasn't tried anything like that yet.

The strategy we've been working with, so far, is to use an FIR filter to flatten out each driver's response on the target axis within its passband, then use the "flattened" responses as input to conventional IIR filters (e.g. 2nd order Butterworth highpass/lowpass) that you might see in a typical active crossover. But more creative approaches might be forthcoming.

We compute the "flattening" filter response by inverting the measured frequency response magnitude, then use the Hilbert transform to obtain the minimum phase (i.e. causal filter). I think this is what Ultimate Equalizer does? The second plot illustrates this concept.

[Michael P]

We assembled the electronics on a piece of plywood for testing: Meanwell power supply, Raspberry Pi, Sure 6x100 W amplifier, and a USB soundcard taken out of its enclosure. I don't know what type of soundcard this is, but I'll try to find out (spoiler: the analog input performs poorly). Everything is powered from the same supply. This came together without needing much soldering. You can see a buyout 8" woofer being used as a canary: make sure it doesn't get blown up before connecting any $100 drivers.

There were some nasty noises at turn-on, and in general bad things when the USB soundcard isn't active. To fix this, we connected a GPIO output of the Raspberry Pi (controlled by software) to points on the amp PCB close to the muting switches. A bit of interface logic was needed to ensure that the amplifier was held in mute when the output was tristated. There are still some noises from the amp outputs, and mechanical noises from the power supply when it's powered up, but not much hiss or hum (even though there is no resistor padding any of the drivers).

Each speaker cable has a single Speakon connector on it with connections for all 3 drivers (thank goodness, that would be a lot of binding post twisting) and the other end ends in a pigtail with individual wires that get screwed into the amp board. It was a bit confusing getting the wiring right, and I think the speakers went to DIY New England with one woofer out of phase. But it's a digital crossover, so you could fix that in software... if you wanted.

Mike and I think the fidelity of the electronics can be improved. The S/PDIF input sounds way better than the analog input. We tried replacing the output filter capacitors on the amp (see http://www.trevormarshall.com/class-d-tutorial/), which made a surprisingly large difference in the sound (cleaning up the treble, mostly?) relative to the stock amp board. Still, the bass improved when we substituted a class-AB amp that I brought. I think Mike is contemplating a beefier amp board specifically for the woofer channels. So far, we haven't done anything about the soundcard, though I'm working on a project of my own that may address that in the future.

[Michael P]

I will try to briefly describe the crossover software in this post, then follow up in the discussion (also, I should get to bed...). With a long enough FIR filter, you can do pretty much anything to the frequency response (EQ, crossover slopes, etc.). There are systems to run these filters in real-time, and while many of them operate on a PC, you don't really need that much computing power to do it; a Raspberry Pi is fast enough. FFT techniques are used to accelerate things relative to a time-domain convolution.* We were amused to see that the crossover only consumes a small percentage (2%?) of processor time according to top. That was with relatively short (1k sample) filters, though there should be enough time to do much longer filters once we get the latency down via partitioned convolution.

This is a free/open-source project, and Mike has posted the source code at https://github.com/axiak/speakers. I contributed a little bit to the filter math. There are 3 main components:
- Low-level C library which performs the FIR filtering efficiently.
- Python code that allows high-level manipulations: loading frequency responses, computing filter coefficients, assigning different filters to different sound card channels.
- A couple of shell scripts that tell the Python code what to do, and control the muting of the amplifier.

One of the cool things Mike figured out is that you can prototype the filter design in an IPython (Jupyter) notebook. So, you can load the driver responses and experiment with filter designs (drawing plots of simulated responses, etc.) by typing a few lines of Python code in your Web browser. And then, you can run a command on your laptop that sends your code to the Raspberry Pi and activates the filters you just simulated. (The code on the Raspberry Pi constructs filters using the same API as the modeling tool.) Those notebook screenshots are showing 4th order filters at 400 Hz and 3 kHz.

* Please ask if I should explain this or any other jargon I may inadvertantly throw into this thread.

[philthien]

What an outstanding project and write-up.

[donradick]

Great project!
I"m going to dive into the RasPi code - I can whip up some Python code pretty easily,
and I've been thinking a lot about active crossovers.

[ani_101]

Would you happen to have a guide or tutorial on how to get your project on to a pi and configure it? Doesn't have to be very details, but something to get us started. I have not messed around a lot with Pi other than install various flavors fo the Rasbian OS with pre-loaded software.

[bcodemz]

This is a very impressive project. Glad to see more people doing a serious active project. I'd like to learn more of what you're doing on the Pi because FIR capable miniDSP's are very expensive. I'm currently doing a similar project that you can see here.

One thing I'd caution. While FIR filters can do some amazing stuff, it can be misleading to over use them to correct everything perfectly flat easily when that will not achieve the best result.

When correcting a driver's response, you should use IIR filters because the driver's response is generally minimum phase, so an IIR filter would correct both amplitude and phase.

Also, it's very tempting to invert a frequency response and achieve a perfectly flat line, but that's not actually optimal. There are things that you should not correct for, such as baffle diffraction and box resonances. Remember a frequency response measurement is a measurement in one point in space, but sound radiates in all directions. The diffraction effect you see when measuring on axis will not be the same if you measure off axis. Therefore, when you correct for the FR anomaly caused by diffraction on axis, you are making the off axis response worse because the diffraction error isn't at the same frequency at a different angle.

Excited to see what's next.

[Michael P]

This is a very impressive project. Glad to see more people doing a serious active project. I'd like to learn more of what you're doing on the Pi because FIR capable miniDSP's are very expensive. I'm currently doing a similar project that you can see here.

One thing I'd caution. While FIR filters can do some amazing stuff, it can be misleading to over use them to correct everything perfectly flat easily when that will not achieve the best result.

When correcting a driver's response, you should use IIR filters because the driver's response is generally minimum phase, so an IIR filter would correct both amplitude and phase.

Also, it's very tempting to invert a frequency response and achieve a perfectly flat line, but that's not actually optimal. There are things that you should not correct for, such as baffle diffraction and box resonances. Remember a frequency response measurement is a measurement in one point in space, but sound radiates in all directions. The diffraction effect you see when measuring on axis will not be the same if you measure off axis. Therefore, when you correct for the FR anomaly caused by diffraction on axis, you are making the off axis response worse because the diffraction error isn't at the same frequency at a different angle.

Excited to see what's next.

Wow, I hadn't paid attention to the small speaker thread. I look forward to seeing what comes out of that. It looks a lot more professional than what we're doing, but maybe the Raspberry Pi platform will be useful for it eventually. (I've contemplated using the Pi Zero in a plate amp since it's cheap enough, but I don't have the experience or time to do it anytime soon.)

The FIR filters we are using are minimum phase; in other words, we haven't tried any time domain equalization (like linear phase). We're aware of the fallacies of flat-looking responses, so I think there will be a lot to learn from listening/experimentation. Mike was able to get a frequency response plot showing how the (mostly baffle-related, I'm guessing) ripple varies on a couple different axes with his initial filters (attached). I think there is about a 20 degree spacing between the curves, and you can see the +/- 2 dB or so of ripple that develops off axis. With enough measurements we might be able to get a handle on what the polar response looks like and thus what the target on-axis should be; and ideally the polar measurements would also inform/verify crossover choices. (I tend to be lazy and just start with 15 degrees as a design axis.)

[Michael P]

Great project!
I"m going to dive into the RasPi code - I can whip up some Python code pretty easily,
and I've been thinking a lot about active crossovers.

Glad to hear it, let me know what your experience is like. I worry that the code might be confusing and/or broken in its current state, but we'll try to improve it over time. (You can use the issues/pull requests features on Github if you're in the mood.)

Would you happen to have a guide or tutorial on how to get your project on to a pi and configure it? Doesn't have to be very details, but something to get us started. I have not messed around a lot with Pi other than install various flavors fo the Rasbian OS with pre-loaded software.

I'll try to get Mike on the forum since he's the one who really knows--I'm embarrassed to say that I don't have my own Raspberry Pi yet, so I've only been able to use the modeling features and test the filters on my Windows PC. The instructions we have now on the Github page are a bit sparse. My guess is that the default OS will work; just install Git, clone the repository and install the needed dependencies using apt.

If you only want to experiment with filters on your computer (like me), you can clone the repository and run "jupyter notebook" from the top directory; you may have to install some Python libraries for that to work.

On the Raspberry Pi, the filters are run within a Python script called filter/runspeakers.py. Mike's setup is to develop the filters on his laptop within an IPython notebook, then copy/paste the filter generation code into runspeakers.py and then run the update_rpi.sh script to send the entire code directory to the Raspberry Pi. I bet we can come up with an easier way to do this. It looks like he also uses Supervisor (http://supervisord.org/) to run runspeakers.py in the background on the Raspberry Pi--see etc/runspeakers/supervisord.conf.

[ani_101]

Thanks. This is a pretty interesting piece, but haven't yet ventured far enough. If you or Mike can offer more explanation it would be easier to follow along!!!

[bcodemz]

Wow, I hadn't paid attention to the small speaker thread. I look forward to seeing what comes out of that. It looks a lot more professional than what we're doing, but maybe the Raspberry Pi platform will be useful for it eventually. (I've contemplated using the Pi Zero in a plate amp since it's cheap enough, but I don't have the experience or time to do it anytime soon.)

The FIR filters we are using are minimum phase; in other words, we haven't tried any time domain equalization (like linear phase). We're aware of the fallacies of flat-looking responses, so I think there will be a lot to learn from listening/experimentation. Mike was able to get a frequency response plot showing how the (mostly baffle-related, I'm guessing) ripple varies on a couple different axes with his initial filters (attached). I think there is about a 20 degree spacing between the curves, and you can see the +/- 2 dB or so of ripple that develops off axis. With enough measurements we might be able to get a handle on what the polar response looks like and thus what the target on-axis should be; and ideally the polar measurements would also inform/verify crossover choices. (I tend to be lazy and just start with 15 degrees as a design axis.)

Haha thanks I wouldn't call it professional. There is still a lot of boxes and wires outside the speaker like the 2 miniDSPs, Wi-Fi streamer, optical splitter and stereo to mono sum box. If it is professional everything would be inside for one, which would be really nice.

Good to know you're aware of these problems. I think with your skill set you can do a lot on the Raspberry Pi platform. Keep it up and I'd like to see more of what's coming up.