Confessions From Studio Dave

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.

______________________

Similis sum folio de quo ludunt venti.

Comments

Comment viewing options

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

64bit up and running here

Suamor's picture

Hi Dave,

Sorry to hear your trouble with your 64bit Studio Dave. I'm nearly in the same boat but with much more success. I choose an Ati X1300 PCIe-GFX card, an ASRock AM2XLI-eSATA2 with an AMD3500+/1G Memory and use an SB Live as primary sound card. I installed succesfully Ubuntu dapper, installed many sound apps and was impressed by the low latency so far. I haven't made too many tests up to now but I've got some important information on this page regarding jack and amd64: AMD 64 Tips

It's probably the best to use a newer jack version than the one included on any Debian-based distro I searched so far. I haven't checked jack version of studio64 up to now though.

Thanks for the Rezound review, I will definitively give it a try on my soon upcoming CD project. I like the cleaner interface compared to Audacity. Anyone knows if jack support is on it's way or patchable?
Ok according to the homepage jack support should be in the next version. Also there is a qt(4) port planned of rezound, so if nobody has ported/reimplemented qtthumbwheel (an commercial-only available Qt solutions widget) these will disappear from rezound in the port :-(. The rezound author seems to be learning qt4 currently in a different project.

wireless network

Anonymous's picture

i certainly appreciate your work on getting a 64 bit audio powerhouse running. i intend to build one this winter when stuck inside. it would be great if you also took on getting wireless to work...

thanks very much for your work.

drop-outs

Anonymous's picture

Dave, your audio drop outs are due to the latest graphics drivers.

they HOG all of the PCI bus cycles as they can-- not leaving much

for audio devices to function. you are not alone in this problem.

Many people report a new card causes such problems and an OLD card

fixes it! j.p.

There are latency utilities

Anonymous's picture

There are latency utilities that allow you to set a max/min latency for PCI/AGP bus. Unfortunately I can't look up the name of any of them right now, but I've used one on a Windoze box within the last year. Should be an equivalent in Linux.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState