Spectral Analysis with Linux Systems and the Merlin DSP Project

Gordon discusses sound cards and the xspect power spectrum analyzer.

In the past few years, there has been a tremendous interest in low-cost, high-performance spectral analysis systems on the part of audio engineers, speaker designers, musicians and instrument manufacturers. Windows systems have long been regarded as unreliable for high-end applications, and consequently such applications historically have been the domain of the professional workstation.

Linux, however, has proven to be stable and well appointed with program and documentation development packages. In particular, the OSS sound driver for the Linux kernel (2.4.6 on my system) works well with SB16 type sound cards.

I should acknowledge the inspiration for this project was in part due to the sterling work of Philip vanBaren. Other DSP packages are around, but I hope that xspect will fill a certain niche.

Sound Cards

Having a sound card with record and playback capabilities is essential. The card need not be full duplex unless the application involves (nearly) real-time digital mixing and recording.

8-bit resolution is not really appropriate for spectral analysis, but 16-bit (or higher) is much better. It should be noted that the DC error (the stream is not all zeroes when there is no analog input) should be estimated and applied at runtime.

On the subject of DC error magnitude and drift, there is an enormous difference in quality between compatibles, including the ALS007, the ALS100 and name-brand sound cards. For the work you will be doing, there is no point on skimping on audio quality.

If you do nothing about the DC error, even with Blackman windowing there is an enormous leaky spike at 0Hz. This is quite enough to render any chi-by-eye laughable.

The card you choose should be capable of both mono and stereo operation. Be aware that the Intel i810 chip set cannot record in mono. So how do you get a mono signal from a stereo one ? Certainly not by taking the arithmetic mean of the left and right components. The power is what's invariant, so the correct procedure is to take the RMS average. There is a separate DC error for each channel; better have the sound card sort that one out.


X servers for Linux have come a long way, and few high-end graphics cards are not amply catered for. Although some people claim that X is slow, this is not true if the X library calls are carefully chosen and scheduled. Clearly, the various X toolkits are too cumbersome and a clearer, leaner approach is called for.

A good way to save time (we always want to do that) in real-time graphical systems is to make fewer calls. If several draws can be calculated for the same GC, then it is much better to fill an array of segments, rectangles and so on, and draw them all with one call.

Where possible, it is better on the eye to avoid erasing whole sections of an application window and redrawing. Instead, it is better to amend the window piecemeal, but this raises problems for rainbow displays when they are zoomed and shifted.

Text indicators that are XFillRectangled, sprintfd and XDrawStringd can be made flicker-free by using XDrawImageString. Remember to set the background colour in the GC.

Using the XOR GC function you can pull some good moves. To erase a part of something. simply redraw that part in the same GC. You can pile up a lot of draws from different XOR GCs and selectively undraw them easily. This saves having to use the background colour to undraw bits of the display.

We don't have time for pesky expose events and clipped redrawing, so it is necessary to use Backing Store for the application and window menus.


I'll add here that the application should never be blocked when awaiting user input. If that happens, the recording overrun messages will soon pile up. To avoid this problem, the main processing loop could like something like this:

    init ();
                while (1)
        check_dialog ();
        acquire_data ();
        transform_data ();
        draw_data ();

The main business of the day--getting back around the main loop before the next buffer is ready--should include a check for any pending dialog requests. These dialogs are in a separate thread and are almost always blocked unless the user intervenes. This means that the dialogs consume few to no clock cycles unless they are activated.

Needless to say, care has to be exercised when mixing threads and global variables. There is no place here for the exorbitant overheads of C++ or Ada, and global shared blocks have to be protected from concurrent access.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

an incredible spectrum analyzer

Anonymous's picture

Great article, xspect looks like a nice project, but if you are looking for a professional PC-based spectrum analyzer that runs on Linux I'd recommend that you check out this amazing Linux program called baudline, it is even free!? What this program does with X-Windows is incredible. We use baudline on several machines for monitoring experiments in our lab and we couldn't be happier.

Re: an incredible spectrum analyzer

Anonymous's picture

Thank you. Please keep your SPAM out of this discussion.

Re: Spectral Analysis with Linux Systems and the Merlin DSP Proj

Anonymous's picture

Uh, I like the article, but where do you find xspect and related code? Google is of little help; the links in .fr are outdated, broken, or point only to docs.

How about Merlin DSP project?


Re: Spectral Analysis with Linux Systems and the Merlin DSP Proj

orpheus's picture

Just email me and I will send you the source code.

My email for this is : gordonamiller@hotmail.com

The Merlin DSP project is an ongoing process eventually leading towards the automatic transcription of musical scores from sampled music.

I am hoping that RedHat will pick up on this ...

Re: Spectral Analysis with Linux Systems and the Merlin DSP Proj

Anonymous's picture

Congratulations, great article - Jane M