The Hard Parts

I hate hardware. Sometimes I hate Linux too, but more often I just hate the hardware. Boxes, wires, connectors, keyboards, mice, the works. Some days I just want all of it to disappear.

Hmm, did I perhaps have a bad time building my new machine ? That's putting it lightly.

New readers should check out my earlier entries to catch up on current events here at Studio Dave. After collecting and assembling the parts for a new and more powerful box I was disappointed to discover that the machine was dead on arrival. When I pushed the power-on switch nothing happened. I opened the box and tried to start it again. I got just about zip, zero, nothing, nada. Actually, the cool blue front panel lights flashed once, the CPU fan made a weak little spin and died, and that was all.

My brother checked the power supply and concluded that it was blown, but he admitted that he wasn't sure he had tested it correctly (many PSUs require a load before they'll operate). So I trundled off to a local repair shop where it was determined that the power supply was fine, but the motherboard was hopelessly burnt. The repairman suggested it was probably DOA when I installed it. Fortunately the good fellow who had supplied the board was willing to give me a complete refund, and I'm now awaiting the arrival of a new motherboard, complete with pre-installed CPU. I'm still going with the AMD64, so you'll still get to hear about Studio Dave's transition to the 64-bit world. It's just going to take longer than I planned.

Once again I must send props and thanks to the members of the Linux Audio Users mail list. Their technical advice is invaluable, as are their supportive attitudes and generosity of spirit. I don't think I could handle this project without their help.

While waiting for the new motherboard I decided to try out one of the new components. I swapped out the GeForce2 MX/MX 400 video card from my current desktop machine and installed the GeForce FX 5200 intended for the new machine. Both boards are build around an nVidia chipset, both are AGP-compliant, and both are supported by the kernel's own nv driver as well as by nVidia's proprietary driver. With this much compatibility I expected a straightforward swap & play experience. Foolish Dave.

The card itself performed well, as long as it ran under the kernel driver. nVidia's own driver failed, and yes, I used the latest version. That's okay, I wasn't planning on any 3D use anyway. However, a greater problem came up, resulting directly from the new video hardware.

A digression: I had pulled my M-Audio digital audio board from the current desktop box, leaving only an SBLive Value soundcard, because I wasn't planning to use that machine for recording anymore. The SBLive is not exactly contemporary hardware, but it's well-supported by ALSA and works as advertised. I used it extensively before acquiring the M-Audio board, and I recommend it as an inexpensive solution for consumer-grade desktop audio services. I even used it for some multitrack recording with JACK and had no problems. "Problems" here equate to the dreaded xruns, buffer over/underflow conditions that can create audible and very undesirable gaps in your recordings. JACK and the SBLive have got along famously in the past, and I expected them to get along famously now. As I said: Foolish Dave.

No matter how I adjusted JACK's settings in QJackCtl I got xruns. Sometimes a lot, sometimes not so many, but always more than were tolerable. I decided to investigate the phenomenon because I had no such troubles in my previous work with the SBLive on the same box and I wanted to find out what was causing the problem.

One common xrun-producing culprit is a bad IRQ number. User Mark Knecht has addressed this situation in his excellent contribution to the Low-latency HOWTO. I ran diagnostics with lspci and cat /proc/interrupts and learned that the SBLive was sitting on IRQ 5. According to the HOWTO, the preferred IRQs for audio hardware are 9, 10, and 11. IRQ 10 is already owned by the AGP slot, IRQ 11 was taken by my Ethernet card. Since my machine doesn't have programmable interrupts (APIC) I had to open the box and swap card slots. Alas, the xrun problem persisted unabated, and at that point I suspected that the video card was the likely perpetrator. I put the old card back in the AGP slot, and the problem disappeared.

I hate hardware.

I did find some silver lining to the whole cloudy experience. While researching IRQs and Linux I discovered Powertweak, a handy utility for probing your system and reporting its hardware and kernel capabilities. Figure 1 shows off Powertweak in its GTK user interface, hard at work exploring the depths of my crappy desktop box. I haven't used Powertweak to change anything yet (I don't understand everything it shows), but it's clearly a cool tool. It's also rather dated. Can anyone out there recommend a similar program of more recent vintage ?

Figure 1: Powertweak Linux

Movens Bene Protinus

It's all good now. I've restored the desktop to its original audio and video hardware configuration, including the M-Audio board. JACK is happy, and I'm into a new project, recording readings of Latin poetry that you can hear (in OGG format) on my Latin Audio Examples page. These readings are probably of limited interest to Linux audio people, but the folks on the Textkit Latin forum might have some fun with them.

The project details are uncomplicated. I used ecasound from an xterm prompt to record a simple stereo WAV file. JACK was active, so I connected the microphone input to ecasound via the Audio Connections panel in QJackCtl. I set my input level with the Envy24Control mixer interface for my M-Audio card and recorded the readings (Figure 2). The resulting files weren't perfect, but I figured I could polish them in a soundfile editor.

Figure 2: Recording with ecasound and JACK

My soundfile editor of choice is usually the all-singing all-dancing Snd, but I wanted to try Davy Durham's ReZound for this project (Figure 3). My necessary edits were common operations, such as normalization, trimming dead space, muting extraneous noises, adding reverberation with a LADSPA plugin, and making incidental adjustments to amplitudes. I needed only a few routines, but I was going to use them repeatedly, so I also wanted them to be simple and easy to employ. The short review: ReZound rocks. The program is loaded with helpful functions and routines for common and uncommon audio editing, and I quickly learned how to expedite my required operations. Then I kept discovering other neat controls for viewing and playback, very helpful for my immediate work, along with many features I simply didn't have time to test.

Figure 3: ReZound

For example, ReZound provides an interface for cdrdao so you can burn your work to disc directly from the editor. Of course, first you should treat your work with the tools commonly associated with an audio mastering suite, i.e. equalization, compression, balance, gain adjustment, and so forth. ReZound doesn't pretend to be another JAMin but it does supply a Remaster menu filled with helpful items that just might save the session on a JAMin-less system.

ReZound's GUI is based on the FOX graphics toolkit. Personally I find its appearance attractive and easy on the eyes. And I must admit, the thumb-wheels are just too cool.

Documentation is sparse but adequate. The docs directory of the source package contains some text files regarding installation details and the interface conventions. Other useful information can found by following the Documentation link on the program's Web site. Judging from my experience I'd say you'll learn the most about ReZound just by playing around with it, consulting the documentation as needed.

I don't know what Davy Durham's been up to lately, but it looks as though development on ReZound is on hiatus (the last public release dates from late 2005). I hope it picks up again, ReZound is truly worthy Linux audio software. Davy, if you're out there let us know what you're doing these days.

Music To My Ears

Two rather different pieces of music came my way recently, one by way of a Csound mail list and one via the Linus Audio Users list. The Csound piece is an extraordinary work by Thorin Kerr titled Diving I (rendering and link to the OGG file courtesy fellow Csounder Dave Seidel). I don't know what operating system Thorin uses, but he notes that this work was created in part with his own Python code. Csound doesn't lack for impressive works (Rick Boulanger's Trapped In Convert and Michael Jude Bergeman's The Face On Mars come to mind), and if you'd like to hear what the latest & greatest new Csound can do, check out Diving I.

The second sonic delight came from Johannes Mario Ringheim. He just popped on to the LAU mail list one day and announced that his Kanskje No was on-line, leaving the rest of us in wonder and amazement. It's a neat piece filled with creative uses for a suite of Linux audio software that includes Ardour, Hydrogen, seq24, and the awesome (and abandoned, alas) ALSA Modular Synthesizer.

Recently the LAU list has seen new music links from Steve Doonan, James Shuttleworth, Carlos Pino, Aaron Trumm, Folderol, Esa Linna, and many others. Not all of this music makes it to the awesome LAM so be sure to check out the LAU archives to ensure that you're getting your full dose of music made with Linux.

Hopefully I'll be 64-bit-savvy by next entry. If not, have no fear, there's plenty of worthy activity in the world of Linux audio software. Look forward to a review of the new crop of multitrack recorders for Linux, a survey of recent music and sound programming languages, maybe an interview or two. Who knows what will show up here next ? You'll just have to tune in to find out.