Last night, on a whim, I decided that I would like my active crossover software to display some sort of indication of the output levels being sent to the DACs. This is quite important, and something that I should have tackled quite a while ago. Basically, we should be worried about clipping, and also ‘overs’ i.e. those interpolated samples that are generated by DAC reconstruction filters in between the recorded samples and which have the potential to clip even though the recording does not, directly. By messing around with various types of driver correction and so on, am I running the risk of clipping? Or, am I wasting DAC resolution by needlessly attenuating my DAC outputs too much?
Here is how easy it was to display the information in a useful and aesthetically pleasing way:
- I created six vertical rectangular areas on the active crossover app’s screen – one bargraph for each DAC output.
- I decided upon a linear percentage display (not dB) and an update rate of 10 Hz
- A timer was set to trigger at 10 Hz (the timer is provided by the GTK GUI library) and call the function to draw the six bargraphs
- In the output function for the DACs, I take the absolute value of each sample as I write it to the DAC and compare it to the maximum recorded so far for that channel (out of six channels). I overwrite the maximum if it is exceeded. There is a ‘mutex’ interlock around the maximum value to prevent the bargraph drawing function from accessing it at the same moment.
- The bargraph drawing function for each channel accesses that maximum recorded value and saves it. The maximum value for that channel is then reset to zero. The saved value is compared against that bargraph’s previous displayed value. If it is greater, a coloured rectangle is drawn directly proportional in length to the value. If it is less, the previous value is multiplied by 0.9, and the rectangle drawn to that height, instead. With this simple system, we have a PPM-style display that shows signal peaks that slowly decay.
- The bargraph display function also records an absolute maximum for that channel, which doesn’t get reset. This value is displayed as a red horizontal line, thus showing the maximum output level for that particular listening session.
The result is one of those attractive arrays of VU meters that dances in response to the incoming signal levels. The results were interesting, and will alert me to any future mis-steps with regard to clipping – it still doesn’t tackle the issue of ‘overs’ directly, however.
But the reason for mentioning it, is to show the power and simplicity of engineering with software. To build a PPM meter in hardware and wire it all up, would not be trivial, and would take days, weeks or months for a commercial product. In software, it takes less than an hour and a half to construct it from scratch. Audio processing functions are equally simple to create and integrate within the system. It seems clear that once the basic DSP ‘engine’ is in place, complex audio systems can be put together like Lego. A perfectly capable three-way speaker can be built in days. It is not too hard to see how a three-way, six channel DSP system could simply be scaled up to create something like the Beolab 90.
Is this an exciting trend, or the end of everything that makes audio interesting? I think it is the former, but I can see that many traditionalists might disagree.
The Rational Audiophile 