Using a Behringer DSP8024 for Room EQ

I have a Behringer DSP8024 Ultra-Curve Pro audio processor on the output of my computer.

Behringer DSP8024 audio processor

I picked up this relatively ancient unit for £50 about 15 years ago (it cost about $500 back in 2001!), and they can still be found on eBay, along with later models like the DEQ2496, and related hardware like Focusrite’s (discontinued) VRMBox. It provides many different audio processing functions, including:

  • Stereo 31-band ⅓-octave graphic equaliser
  • Real-time stereo 31-band spectrum analyser
  • Stereo 6-band parametric equaliser
  • Delay up to 2.5 sec
  • Noise gate
  • Automatic “feedback destroyer”
  • Accurate level meter with selectable scales
  • “Brick wall” limiter for output protection
  • Automatic room equalization using microphone input and internal noise generators

It’s this last feature that is the most useful, combining the analyser with the graphic equaliser. Room equalisation (EQ) can correct a lot of acoustic deficiencies in a room. The shape, composition, and contents of a room, and non-linearities in your speakers and audio interface all contribute to how audio sounds within it. Ideally you want to minimise these effects so as to hear as true a signal as possible. It’s a good idea to apply corrective EQ after adding simple physical acoustic controls (e.g. absorber panels, diffusers, and bass traps, or just old duvets and cushions). Room EQ gets some criticism from audiophiles because it can be very hit & miss and can’t address bigger issues, but it can work very well if you listen from a single location in your room (e.g. in front of your desk).

To measure the room equalisation accurately, you need a microphone with a flat (or at least well-documented) frequency response; I use a t.bone MM-1 for this.

The t.bone MM-1 measurement microphone

The equalisation process works like this, starting from flat EQ (no alteration):

  • Output pink noise from the unit through the speakers
  • Analyse what it sounds like through the microphone, from your usual listening position
  • Alter the equalisation towards a flat response
  • Iterate over this process until the overall response is as flat as possible

This process is loud and quite unpleasant, so leave the room or stick on some closed headphones while it’s busy! It takes a minute or so, and you can hear the change in characteristic of the noise playing through the speakers, and see the changes in EQ on the screen of the unit during the process. After it’s done you can save the EQ curves, and switch the EQ in and out to A/B the config. The difference is pretty noticeable, particularly at the low end where most room-related acoustic problems tend to be; overall it’s like having a major speaker upgrade! One benefit I really notice is when switching between my corrected speakers and a decent pair of monitoring headphones – the audio really doesn’t change in character; there’s no significant tonal shift between the two.

Some people have noted problems with “digital noise” when using this unit, particularly at low volume levels. I suffered from this for a long time, but then realised what caused it and solved the problem. If you have a volume control that is before the processor, you will end up with a small signal going through the analogue to digital converters (ADCs), effectively throwing away much of their available resolution, and you’ll get a lot of quantization noise as a result. The best way to hear this deliberately is turn the input level down, and the output level up, then play something smooth and quiet. It will sound horrible, gritty and noisy, you can really “hear the bits”. This isn’t a problem unique to this unit – any ADC provided with insufficient signal will suffer the same problem.

You want to maximise the use of ADC resolution by giving it a full-range signal to convert. So if you have an audio interface before it, make sure it’s turned up full, and if you have any software level control (e.g. macOS system volume), make sure that’s turned up full too, so you’re always sending a full-volume signal. This way the converters will always use their full 24-bit resolution and the quantization noise will be so small you won’t hear it (it’s impossible to remove completely). However, you still want to control your output level. There are 2 ways to do this: alter the level on your monitors (which can be inconvenient as volume controls on active monitors are often on each speaker separately, and often hidden around the back) or use a passive volume control between the equaliser and the speakers. I use a Mackie Big Knob Passive for this.

A Mackie “Big Knob” passive volume controller.

Passive volume controls have no power supply (so no noise or extra cables), and can only turn a signal down, not up. It’s analogue, so there are no DACs or ADCs, just simple passive components. Ideally when it’s turned up full, it should be indistinguishable (acoustically speaking) from a length of cable.

Controlling level directly on the speakers (or on a separate amplifier if you have one) is possibly better than this approach, but usually less convenient. If you want to be able to run your speakers at full volume via the passive volume control, you need to have the monitors turned up full, and this often means you’ll get significant analogue noise (hiss) from the speakers when you’re listening at lower volume, however, that’s generally less unpleasant and not the problem we’re addressing here.

All of this attention to correct signal levels throughout an audio signal path is part of a wider concept known as gain staging, and occurs in many other places in audio recording, processing, mixing, mastering, etc.

It is possible to do all this processing in software using systems like REW or RoomEq, or even to go further and emulate other listening environments, famous studios or speakers, but I quite like having all this externalised and independent of software, and it also means that it can be applied to external inputs too, if you’re playing an instrument directly through a mixer. The “big knob” also provides a very convenient single control for output level, along with other features such as mute/dim and speaker and input switching.

…and after the MVP?

You may be familiar with this triangle representation of a “Minimum Viable Product”, or MVP. The idea is that you have a product that contains just enough of all its critical components to be actually sellable, and the pink shaded area represents the amount of work or resources required to bring it to fruition, out of the “full” range of possibilities if budget/resources were not an issue. This diagram is usually presented side-by-side with this one that shows a contrasting “bottom up” approach:

The same amount of resources just fills the bottom layer, giving you lots of functionality but no way of using it, making it unsellable.

That’s where the analogies generally stop. I’ve encountered several misunderstandings of what happens next. Firstly, “the same, but bigger”, where more budget arrives, accompanied by a matching expansion of the spec:

Sure, you get “more” built, but it’s still the same proportion of what you’re aiming for, so it has not really progressed beyond the MVP.

Next we have the “expanded spec”, where the intended implementation is increased, but the MVP implementation stays where it is (i.e. no additional outlay). While management might want the MVP proportion to scale with the spec, of course that doesn’t happen – you have just made your MVP proportionally smaller rather than bigger, likely breaking its “viable” status:

Next up, is “do the same again, because scaleable”!

This is clearly a management disaster, and might be illustrated by jumping straight into a basic project using kubernetes and microservices, or perhaps writing the first page of all the chapters in a book. You will drown in complexity while achieving less than the intended MVP.

The missing image is very simple, I’ve just never seen it actually drawn; it’s this:

Stick to your plan, implement more of it as resources and budget permit. This may involve rebuilding some of the things you did earlier but bigger/better/differently, not just adding. There is another common set of these diagrams that uses a skateboard / scooter / bike / motorbike / car progression analogy that does work a bit better to convey that (e.g. both skateboards and cars have wheels, but skateboard wheels are not good enough for a car). That’s all.

Should I build a PHPMailer video training course?

I spend a lot of time working on PHPMailer, and even more answering questions about it on Stack Overflow, yet gain very little from doing so. There is a certain amount of professional pride and reputation involved, but that doesn’t pay the bills. I am lucky enough to have a few GitHub and Patreon sponsors (thank you!), but that doesn’t amount to much. The same questions come up again and again, and repeating the same answers over and over, to people who are convinced that they must be the very first person ever to have had trouble sending email through GoDaddy, gets dull and tiring. I also run Smartmessages.net (a privacy-first email marketing service), so I am continuously exposed to large-scale email issues that small senders never have to worry about, but that are near-impossible to find advice about.

Email is a funny thing; it’s been around forever and is absolutely taken for granted, but it’s horribly complicated (way more so than, say, HTTP), and many developers, especially new ones, have absolutely no idea how it works – hence the repeated mistakes. Email grows more complex by the year, with the addition of things like SPF, DKIM, DMARC, ARC, MTA-STS and more. Some of it is really quite tricky yet the resources available for it either suck or are decades old. I’ve previously pitched book proposals to popular publishers (including O’Reilly and Packt) on “Modern email”, but have always been rejected on the basis that it’s not of interest or “outdated”, even though email usage is forever growing and changing.

So I’ve been thinking about putting together a training video course on using PHPMailer, diagnosing related problems, and using email in general. Such courses are apparently very popular, though I have to admit to not using them much myself, preferring text. I’ve been heartened by the success of projects such as Christoph Rumpel’s Laravel Core Adventures, along with his valuable advice on how he built that. I’ve been impressed by the lovely Jeff Geerling‘s dedication to his ansible book and audience, and have contemplated going the self-publishing route, but a book is a really big commitment, especially on such an enormous subject as email. Video courses are a bit more flexible, though keeping them up to date has its own issues, as Jeffrey Way has said about his amazing output on Laracasts.

The big issue is my audience. I know that it’s going to be primarily junior and novice developers with little experience needing help putting together their first contact form, so it needs to be pitched quite low, at least to start with. I gather that the primary feeder for video courses is social media, but my social media profile (principally Twitter; being a privacy advocate means I really don’t want to go anywhere near Facebook) is mainly more experienced developers, who are probably not the ones who need this kind of help, though you never know – it may just be my impostor syndrome assuming that all these clever people already know about this stuff!

In summary: there is fertile ground for such content, there’s little competition, I’ve got all the experience, equipment, and position needed to do it, but I need some help and encouragement with putting together a platform and reaching my audience. Finally, since I really need to dogfood this sort of thing, please sign up to my PHPMailer mailing list!

Minimal jQuery and extensions in Laravel

I recently needed to add a simple tag editor to a form input. I initially thought that Vue might help with this. That was a big mistake! Vue is seemingly pretty hopeless for this kind of thing – you can’t really use it for “sprinkling” JS elements, and progressive enhancement is a complete non-starter; that’s really more the domain of old-school jQuery, though I hear good things about alpine.js for this kind of enhancement. I learned a lot about Vue that I hadn’t planned on doing, but the overall impression was that it was simply the wrong tool for the job. I am not interested in building an SPA, and I’m certainly not out to rebuild my entire site just for sake of a single widget! My analogy for Laravel and Vue is like oil and vinegar in a salad dressing; they will happily coexist in the same bottle and taste great together, but they really like to be separate.

So, back to jQuery I go. jQuery was disabled by default in Laravel 6, but it’s just commented out in resources/js/bootstrap.js. It’s already included in the npm packages.json config file, so running npm install loads it into node_modules. I was really unclear about how additional JS modules should be added to Laravel using Mix. This was also a bit confusing because there isn’t really much you can point at and say “that’s mix”; it really comes down to what you put in webpack.mix.js in the project root and the npm run devscript that builds assets. However, the main thing that this does is load app.js, but then I found that things like this should be added in bootstrap.js (which is loaded by app.js) rather than adding them to the the mix config.

So the aim of the exercise was to add a tagging UI widget that takes a standard text input full of comma-delimited terms, and turns it into a pretty clickable tag element. Out of many worthy options, I settled on Tagify. After adding it with npm i @yaireo/tagify --save I had trouble figuring out where to actually load it from, but eventually I got it working by adding:

require('@yaireo/tagify/dist/jQuery.tagify.min.js');

to my bootstrap.js file, and evidently this looks in node_modules/to find the file without any additional help. After this I created a script in public/js/editthing.js (because inline scripts are worth avoiding if you’re serious about your CSP) that turned the standard input into a tag widget:

$('#tags').tagify();

and this script was loaded from blade using Laravel’s asset helper, which creates appropriate base URLs for public resources:

<script src="{{ asset('js/editthing.js') }}"></script>

I sometimes find Laravel docs and articles infuriating – there is often both too much and too little information at the same time, or they say things like “just add it to mix”. Many articles on simple subjects like this subvert Laravel’s features to shortcut to “working” (but ultimately counterproductive) solutions, and I wanted to approach this “the Laravel way”. For that reason I thought I’d make detailed notes for these very simple steps that I couldn’t find written down together elsewhere!

HTH