Sigproc

I only use the ALSA sound architecture for GNU/Linux, and I find it very good. I have some notes on how to install ALSA which might be helpful, though they are probably a little out of date by now. Recording uses the arecord program, which is in the alsa-utils. There is a high chance it is already installed on your system if you installed ALSA from your distribution.

You use alsamixer to set the channel you want to record from. This will probably be the microphone channel (space-bar switches capture on). You also need to activate microphone boost. On my setup, with a soundblaster, i do this by unmuting <Mic Boos> (M toggles the mute setting). You could also acquire your sound sample from a CD, or from line in. It’s up to you. An example invocation of arecord would be:

This will record 5 seconds, 1 channel (mono), with a sampling rate of 44.1kHz (the same as CD audio). The output is a wav file, with 16 bits per sample (two bytes), and Linear Encoding. There are other options you can use, but these are a good place to start. In particular, i think it is best to work in mono unless you have good reasons to do otherwise (I don’t, and I have not investigated the complications).

It is probably a good idea to listen to the sample you have just recorded, to check it is what you think it is. You can do this using

or by playing the wav in xmms or whatever you like.

To process the sound sample, I needed to have the samples in essentially an ASCII text-file format. There are various ways to do this, and I have used several as a consequence of initially being ignorant of the "Right Way To Do Things". In truth, i probably still do not know the "Right" way, but I’ll describe a few of your options.

Sox is a fantastic utility for converting sound file formats. One option it has is to convert to the "dat" file format. It is described like this in the man page:

Using sox in this way is simplicity itself:

The first line in out.dat starts with a ";", and has info on the sample rate. The dat file produced here is very easy to read into a python program (or indeed a program in any language). It is also suitable for immediate plotting with Gnuplot if you strip off the initial line containing the semicolon (or put a "#" at the start).

Before I realised that sox had done all my work for me I tried a couple of other options. These aren’t clever or smart, but they show how easy it can be to mess around with sound formats.

The first thing I tried was a solution completely implemented in python. This was slow, but it did work. The code went as follows:

Another, only slightly different approach was to use sox first (remember, I didn’t know what sox could do when i tried this!), to turn our wav file into a raw file, with signed samples, and two bytes (1 word) per sample:

Then back to python, and do:

contents=open('m.sw','r').read()

At this point, "contents" has the same form as it did in the previous python code, and the output can proceed as before.

As a final aside, it might be of interest to know that it is very easy to write a small C program to take the out.sw file above and turn it into a "dat" style file with one sample per line. The code is in convert.c. Ultimately it is useless, as it does nothing sox doesn’t do, but it is very very quick compared to the python implementation (No surprise, I suppose, but I was still a little taken aback by the speed gain even with my limited C coding experience).

This is really quite easy, assuming you have Numerical Python and the FFT modules installed. Continuing from our last code snippet, where "out" contains a list of the samples from our sound file, the following gives us an FFT:

It is as easy as that! To put the FFT data in a file suitable for plotting in Gnuplot, the following code was used:

Now, depending on your knowledge of FFT’s (Fast Fourier Transforms) the above might need some explanation. First of all, the FFT data produced will be complex. However, we are looking at a purely real signal, so we will discard the Imaginary part. Also, only half the data is useful, as the other half is just a mirror image (if you looked at the imaginary part, it would be a mirror image multiplied by -1). Also, you can look on the index of the FFT as meaning the number of cycles occurring in the time-duration of the total sound extract. Thus, the 0, first component is the DC component. The index 1 sample reverses once in the time duration, the next one reverses twice, and so on (lowest frequency is on the left!).

To view the output, you need to use some graphing software. Gnuplot is one good option. Included below are thumbnails (links to full size) of an original time-domain signal, followed by the entire FFT data (as output to file by the python code above). And a smaller detail of the region where most of the interest is, between 1000 and 2000 Hz.

Gnuplot code to produced these figures is included below:

For what it’s worth, the signal analysed here is a 5 second (220500 samples) recording of two notes from a harmonica.

These have just been some quick and sketchy notes on how to analyse a sound input and find out what frequency content it has. As you can see, there is nothing very clever or difficult to the implementation of this, but it is still (in my opinion!) interesting to do. If you have more interesting sound inputs to work on (e.g. vibrations from a machine) you could proceed even further with your analysis and use it as a tool for locating the source of the vibration and noise.

There may be typos in the code snippets in this article. However, you can download the archive of code [Not up yet], which I have run and used to produce the figures included above. Even though that does not mean there are no mistakes, it does at least mean you can reproduce my results (Note that the sound sample is included in mp3 format, to save my webspace and bandwidth, so you will have to first convert it to a wav file. xmms can do this for you using its cdwriter plugin (plays an mp3 into a wav file)).