Menu
Index

Contact
Atom Feed
Comments Atom Feed

Similar Articles

2009-09-21 18:57
Page allocation failures and other wierdness
2009-06-20 13:09
R1800 Gutenprint tricks
2010-03-20 21:52
apcupsd stats on Cacti (via SNMP)
2015-10-25 08:02
Ubuntu/Debian/Linux Mint and AWS CLI Autocomplete
2009-10-31 11:03
Linux (Debian, Ubuntu) SNMP basics

Recent Articles

2019-07-28 16:35
git http with Nginx via Flask wsgi application (git4nginx)
2018-05-15 16:48
Raspberry Pi Camera, IR Lights and more
2017-04-23 14:21
Raspberry Pi SD Card Test
2017-04-07 10:54
DNS Firewall (blackhole malicious, like Pi-hole) with bind9
2017-03-28 13:07
Kubernetes to learn Part 4

Glen Pitt-Pladdy :: Blog

Simple Gtk Audio Real Time Analyser (RTA)

Having a background in audio I frequently find myself wanting a simple RTA to check out what is going on. There are loads of RTAs available for smart phones (can't say I trust the microphones or audio path in a phone), Windows and Mac, but a distinct lack of simple RTAs for Linux.

I did previously hack together a crude one in C using an array of Gtk progress bars about 6years ago, but it turns out progress bars seem to have a horrendous CPU overhead with rapid updates (actually, it's X that goes nuts on the CPU rather than the application).

RTA Take 2

This time I decided to revisit the subject. The basic spec is:

  • Usual ISO bands, plus a few extra on the ends
  • Uses ALSA directly - ensures nothing is messing with the audio (eg. resampling)
  • Semi-intelligent auto ranging / normalisation
  • Saving of responses as .csv files for further analysis

I based this on the previous C one as all the processing is already there, but fixed up the audio to use ALSA directly which is a bit of hassle but worth it for the peace of mind. Currently it supports the two sample formats that any of my 5 different sound devices have so with a bit of luck will be fine with most out there.

This time I used GtkDatabox for display which provides an efficient graphing widget that understands Log scales and more.

Building / Running

This will require a version of GtkDatabox that supports grid arrays - I snatched the source from Ubuntu Oneiric and build that on Lucid (I prefer to stick with LTS for stability).

Other than that make sure you have all the needed build libraries and run "make".

See the Audio Test Tools bundle in the Sine Sweep Analyser article for source and binaries.

The binaries in the tarball are built on Ubuntu Lucid 64-bit and linked against GtkDatabox 0.9.1.

To use the RTA type something like:

$ ./rta hw2:0,0 1

That will start the RTA on the ALSA device hw2:0,0 which using channel 1. The RTA should automatically select the maximum sample rate for the device.

Simple Gtk Audio Real Time Analyser (RTA)

The RTA provides an Input Level monitor to make sure you stay within the useful range of the sound device. Typically for best results you need to keep the level in the top half of the bar while giving a bit of margin against the top (Clipping).

Waving the mouse cursor over the graph will put a marker line on the nearest ISO frequency (or extras I added) and give you a running readout of the level.

Audio Hardware

The usefulness of this depends largely on the Audio Hardware used (capture device and Microphone). If the capture device and/or microphone have a wonky frequency response (as do many) then the results are going to be similartly wonky.

On-board audio is almost universally very poor quality (though vendors and the "good enough" brigade will no doubt tell you otherwise), especially on laptops and portable devices where the frequency response is often severely limited.

My preference is for an off-board (USB) device from a specialist audio vendor (as opposed to a mainstream computer hardware vendor which will probably give you far less for your money). The higher the sample rate, the better. Yes, before anyone chirps up.... the reason is simply that it allows anti-alias filtering to be put well out the audio band so is less likely to affect measurements. No guarantee that they do actually put the filters outside the audio band though.

Bit depth is far less important for this as there is no real dynamic range involved in test signals (Pink Noise), and the RTA graph only has 30dB of range on it anyway. While it may be restrictive with high dynamic range music sources, 16-bit or better device should do the job here with ease.

The choice of Microphone can be a bit more tricky. There seems to be a load from different brands many of which all look identical (other than perhaps the colour they are painted), and a huge price range. I chose the Behringer ECM8000 as I got that way cheapest, but there are many other brands that will do the job including some DIY options around.

My audio capture device is an old M-Audio Mobile-Pre I got off eBay for £35. This is handy as it's got balanced XLR inputs and Phantom Power needed by many measurement microphones. The only downside of it is the 48kHz sample rate, but otherwise it seems to do the job well enough.

M-Audio Mobile-Pre with Microphone for RTA

Test Signals

For RTA measurements typically Pink Noise is used. There are loads of test CDs available with Pink Noise on and plenty of software that can generate it.

If you get stuck then Audacity can generate Pink Noise for you. I would suggest you set an amplitude of 0.7 or less to reduce the chance of clipping. It's worth noting that Audacity's Pink Noise appears to be rolling off for 20Hz where it seems to already be ~1dB down so may not be suited to extremely low frequency measurement.