Designing PPM Audio Meter
Are you thinking about doing PPM audio software development project? Check out my musings in this short article that hopefully provides additional insight into the technology. I welcome your comments.
During the course of our MultiScopeCompact development, our first audio scope, the PPM has been completed. It will be part the planned a suite of audio measurement tools that will eventually be available for MultiscopeCompact users and be part of our updated Video SDK library for developers. I thought it would be a great post to share what we have discovered and implemented for our version of a PPM.
I will not go into the software design details, just an overview of the main design points to consider.
First off let’s define the PPM. It stands for Program Peak Meter. It’s a definition that has been around since the early VU meter days of the 30’s, but not in its more modern digital form we see today.
There may be some confusion as to the real name for this type of digital meter when compared to the earlier PPM analog needle deflecting cousin. You could use the term DPM (Digital Peak Meter) instead. But PPM is the term most familiar today with users so I’ll stick with PPM for this article.
To be clear, a true PPM facilitates some degree of integration of the audio signal before being output to its display device, which can help in handling program peak overloads, but in so doing hide true instantaneous peak values. I would imagine back in the 30’s it didn’t matter much, unlike today’s broadcast constraints. A DPM on the other hand is more accurate and responsive in reading audio peak values as there is no buffer averaging. This does not preclude that a DPM ignores overload conditions. It doesn’t. There still is a requirement to consider adjustments for some level of headroom to keep any clipping at bay.
A DPM’s purpose is to indicate that instantaneous audio signals being input are not being clipped. The assumption of course is that the audio signal will not experience any overload conditions later in the audio programme stream; thus the concept of the Alignment Levels (AL) and Permitted Maximum Levels (PML) being incorporated in the form of emphasized graticule markings. There is no predictor for overload here just best guess that it may happen. So PPM meters have limits in critical usefulness. That is not to say it’s great for simple and fast audio adjustments. The LUFS (Loudness Unit Full Scale) philosophy and metering seems to be the upcoming Holy Grail to handle this volume change condition over time. It will handle the aspect of ‘LOUDNESS’ much better.
PPM’s calibration is marked by the range of digital bits it is planned to display. The scale in our case is called DBFS, or db full scale. This type of display is characterized by defining the 0 db point as the full digital scale of 16 bits or 65535 (not really, more on this later). I’ll be using 16 bits as the point of discussion here. Meters can also be built using 8 bit and 24 bit quantized audio signals.
We have loosely adopted the SMPTE (IEC 60268-18) scale range as our calibration markers, where readings are referenced to 0 DBFS; -20dbFS AL and -9dbFS PML. There are other standards like Nordic for example that have different references and calibration markers.
Ok, the Audio Math and other Considerations
A sixteen bit audio sample can be represented in a range from 0db to about -96db. Notice the negative sign. Audio will be measured from the maximum reference, down.
20log (65536) = 96.3db.
Most PPM’s will not offer the full range of -96.3dbFS, but rather -90dbFS (+/-15bits) as the smallest sample to be output. Or, 20 log (1/32768) = 90.31 dbFS; 6db less than -96dbFS. This fits nicely into the fact that audio PCM bits are read as positive and negative values of 15 bits each way; 32767 positive and -32768 negative. So we can now determine the minimum audio level that can be output, that being -90dbFS if we wish. However, we have chosen to use a range of 0dbFS to -48dbFS for display purposes, in other words we will still process the full bit range, but only display the 8 most significant bits as the first pass of our design, not the full 15 bits. If there is feedback from our customers for more range, we will then change the parameters in a later revision.
The other aspect to an audio meter of this type is the requirement to ‘hold’ and decay the display indication (re: data) from the last reference peak. Without a decay function, the display will only show the last highest peak and stay there, unless there is yet another higher peak and stay there. Not to useful.
We do not do any ‘hold ‘function in this version of our PPM. Holds can be perceived just by the action of the PPM peaking and decay cycle. An update on our PPM may include a ‘hold’ bar, maintaining last peak value for a second or so then drop and dissolve away until next peak. Think Winamp.
Since we have a DPM, audio sample peaks are displayed quickly and having display data decay at a much slower rate will allow time for a peak to be read and to reduce eye strain at the same time. Fast bouncing up and down can be annoying. There are standards for decay, measured in db/sec.
You can use a value like 10db/sec as a starting point (if that is within your design concept) when coding the PPM decay function. Test it to see what works for you. I doubt anyone would be critical of the decay rate chosen as long as it does its thing and is reasonably comfortable to watch.
Using a benchmark like 10db/sec assumes you have an accurate handle on the how long things take to process before the decay function is revisited. To stay independent of system timing and to avoid complex event handlers, a simpler approach would be to assign a fixed decay value that best matches the visual performance of the PPM. When it comes time for the decay to engage, just drop the current display setting by the assigned drop amount and it becomes a temporary new peak on its way down the PPM scale. Should a higher peak occur during a new scan and compare process, it will then reset to that newer peak value. This all happens quite quickly, so I doubt very much the display updates can be seen for what is really happening. Your eye will integrate out a lot of the fast stuff.
At first, assign a big number like [20 log (128/32768)] (remember the display operates in db so the decay value must be in db). This potentially represents a full scale drop of 0 to -48dbFS in one go. Try it out. Adjust for smaller values if need be. You will find out that the drop values will more than likely be intercepted and reset for a new peak value before it has a chance of bottoming out on the display. Smaller drop numbers will perceptively slow the display peak and perceived hold process.
When processing real-time audio there is always the consideration of whether the available processing power is available to handle the audio streams without dropping data. You don’t want a situation where an audio buffer has not been fully processed before the next audio buffer is available. So threading, O/S background operations, audio buffer size, coding language, data processes, event handler interactions etc., are part of design considerations.
Our software application code executes in loop mode, like many repetitive processing applications. So all code functions are in-line, where some processes have been designed within the loop with threading in mind.
So in brief, when coding, assign a PCM Reference (32768), a db min (20 log (1/REF)), a db max (0DBFS) as static and assign a variable for the actual peak value. All audio samples are read in the buffer, which includes both positive and negatives values. Just make all data fetches absolute before determining a peak value and subsequent db conversion.
Assign a buffer size. Keeping the buffer small will help in loop speed. We use sub 1KB size (keep in mind that the buffer will have two channels to process). The audio buffer is scanned for a max value and when found is compared to the last displayed peak value. So a small buffer size is a good idea for fast scanning and processing. If data is being dropped, make the buffer bigger, but there is a balance between buffer size and your computer processing speed. Using an old computer for end use is not a good idea when developing this application. A fast multi-core machine is your best bet.
Make sure to handle cases where the data read may be 0. The log calculation won’t like it.
Our loop processes are simple, assign the first peak value (0dbFS) and begin the decay process, scan the buffer for a peak value, compare against current display peak, replace if higher, toss or ignore if lower than the current peak. Start decay from current peak, get next buffer, scan for peak, compare last peak and display any new peak, etc.
If all is according to Hoyle, you should see the display pop up on peak values, hold, then decay if any new peak values aren’t higher than the last output. Sustained low level in the programme stream or no audio signal will have the display show the decaying process fall all the way down to the dbMin area and just bounce around due to random signaling or noise. Experiment with the decay value and audio buffer size for your application for best performance and visual operation.
Just a note, it is somewhat worrisome that the lower 8 bits of the audio signal is relegated to the dust bin as just noise. I have noticed other PPM scopes on other products do the same thing in terms of just showing the upper 8 bits; curious indeed.
For your PPM display, use ready made progress bar component as your display container or if you are up to it, build your own as a graphics object in OpenGL like we did.
Of course test your application by using calibrated audio test files before interfacing to the audio input hardware. These test signals are continuous sine files calibrated to several known peak db values. I can provide a number of files for you if you want them. Just email me. The files are used to verify your calibration marking on your PPM display. Test in 6db decrements from 0dbFS. If you have a calibrated audio signal source and an oscilloscope, that will work as well.
If you have any questions or comments please use the discussion area below….
