I didn't feel like working with the kernel modules any longer, so I thought I'd try the commercially-available OSS/Linux package from 4Front Technologies. The excellent OSS/Linux setup utility (Figure 1) identified the NeoMagic NM2200 chipset as the default sound system, yet no services were available. A quick exchange of messages with 4Front's technical support solved the problem: I deleted the NM2200 driver, replaced it with the NM256 driver, and voila, I had PCM and CD audio along with the OPL3 synth, and I had no trouble with audio resuming after a suspend mode, all on a brand-new 2.4.18 kernel. Audio performance was as good as it gets for this hardware, but the OSS/Linux package includes a very good equalizer and 3D effects for sound shaping and enhancement. I should also note that 4Front's support was very prompt and helpful.
As you can see in the screenshot, OSS/Linux designates the Yamaha OPL3SA/WSS (Windows Sound System) chipset as one of the main ingredients making up the NM256. It also defines an interrupt and base address for the (non-existent) external MIDI port.
OSS/Linux provides otherwise-unavailable support for cards and chipsets the manufacturers of which require an NDA before coughing up their driver specifications, so if you can't find a driver for your chipset in the OSS/Free or ALSA packages, you might be able to find it in OSS/Linux.
Figure 1: The OSS/Linux soundconf utility defines the NM256 audio capabilities
ALSA At Last
I originally intended to run this machine under a Debian installation with ALSA sound drivers, so I downloaded the ALSA 0.9.0rc2 packages and built/installed them according to the instructions. Alas, I couldn't find the right combination of modules that would give me at least the capabilities of the OSS/Linux and older kernel modules. The NM256 module didn't work: it loaded all right, but I had no audio capabilities from it. I tried using the AD1848 module and got the same results. Fortunately, Takashi Iwai helped configure my machine by using the CS4232 module. First he added this line to my /etc/modules.conf file:
options snd-cs4232 snd_port=0x534 snd_cport=0x538 snd_mpu_port=-1 snd_fm_port=0x388 snd_irq=5 snd_dma1=1 snd_dma2=0
This information defines the card capabilities with values similar or identical to those found in the BIOS. Takashi verified that the correct base address for the audio port in this hardware is indeed 0x534, with the control port at 0x538. There is no MPU MIDI interface hardware (hence a value of -1), but the OPL3 is where it should be. Note that the IRQ and DMA values are also unchanged from those found in the BIOS.
With the chipset's options defined, I could now load the ALSA modules via this small script:
echo "Installing ALSA..." modprobe snd-cs4232 # load CS4232 module modprobe snd-seq # load ALSA sequencer module modprobe snd-pcm-oss # load OSS/Free PCM compatibility module modprobe snd-mixer-oss # load OSS/Free mixer compatibility module modprobe snd-virmidi # load ALSA virtual MIDI module # load 4-operator patches into OPL3 (using ALSA's sbiload utility) sbiload -p 65:0 -4 /etc/std.o3 amixer set PCM 57 unmute # set value for ALSA mixer PCM channel amixer set Aux 28 unmute # set value for ALSA mixer Aux (CD) channel echo "ALSA installed !"
Note that this method is not the way recommended by the ALSA documentation (which suggests using the
alsactrl utility), but I use it because I sometimes need to quickly load and unload the ALSA and OSS/Linux modules while testing Linux audio software packages. Note also that the ALSA mixer is muted by default, so you must set channel I/O values with an initialization script (
alsactrl or something similar to the script above) or by using a software mixer such as
gamix (Figure 2) for X, or ALSA's own
alsamixer at the console.
Figure 2: Using gamix to set mixer channel values (CS4231 here == CS4232)
At this point I again had PCM and CD audio services, along with the OPL3 synthesizer and support for applications requiring the legacy OSS/Free API. I also installed ALSA's virtual MIDI module, giving me access to a virtual second soundcard with four virtual MIDI ports that could be accessed as though they were true MIDI hardware.
But of course I couldn't just stop there and be happy ...
Putting It to Work: TK-707, TIMIDITY++, and Takashi Saves the Day
TK-707 is a wonderful software reincarnation of the Roland TR-707 drum machine. Most of the features of the original have been retained, and an excellent Tcl/Tk GUI accurately recreates the TR-707's appearance (Figure 3). As of version 0.6, TK-707 is unmaintained, but Takashi Iwai has supplied three small patches to keep this software alive and useful. One patch prepares the TK-707 sources for compiling with ALSA 0.9.x, while the others correct the behavior of the program's Ports window that defines its MIDI I/O.
Armed with Takashi's patches, I upgraded and rebuilt TK-707. Alas, although the program would load, it would freeze after a few measures of play, locking my machine completely. Takashi informed me that a bug in the ALSA timer was causing this behavior and that it had been repaired in ALSA CVS. Under his careful guidance I compiled and installed the latest ALSA drivers, prayed for some luck, and ran TK-707. Ahh, satisfaction: no freeze, no lockup. (Note: The timing problem in ALSA 0.9.0rc2 has been repaired in the latest publicly-available packages.)
Getting TK-707 and ALSA to play nice together was only the first step in my plan. I could now set up TK-707 to send its output to the OPL3, but I was certainly not pleased with the sounds from that chip. I recalled reading in the TiMidity++ HOWTO (by none other than Takashi Iwai) that mentioned a way to use that program as an ALSA server/sequencer. If I correctly understood the article, I would be able to route the output from TK-707 into TiMidity++ and access the better sounds of the Gravis Ultrasound patches (GUS PAT files) or SF2 soundfonts. However, in order to do so, I would need to apply a patch to TiMidity++ (from Takashi of course) and rebuild that program, too.
Alas, due to a bug in the configure scripts, I could not compile TiMidity++ in versions 2.11.2 or 2.11.3. Takashi suggested I build and install the 2.12.0-pre1 development package that had already integrated his patch into its sources. This suggestion worked, and I built and installed a version of TiMidity++ that could function as an ALSA sequencer client by running it with these command options:
timidity -iA -B2,8 -Os -EFreverb=0 -EFchorus=0 &
-iAdefines the interface as ALSA sequencer
-B2,8sets buffer and fragment sizes
-Osdefines output mode as ALSA PCM
-EFreverb=0turns off the reverb effect
-EFchorus=0turns off the chorus effect
The MIDI-to-WAV rendering engine in TiMidity++ would then be available as an audio sequencer/server for other ALSA-aware applications, such as TK-707. By default, TK-707 would access the GUS patches defined in my /etc/timidity.cfg file; however, I also wrote another TiMidity++ sound configuration file called timidity-sf2.cfg that contains only this line:
-c /etc/timidity-sf2.cfg to the TiMidity++ command options shown above, I would also be able to access the General MIDI drums and percussion available in that soundfont file.
So after all of this effort, did it work? And were the results really worth that amount of effort?
I ran the command sequence shown above, made a few magic passes over the machine, then I fired up TK-707. When it loaded, I opened the Ports window (Figure 4), selected and saved the TiMidity++ port for my output interface, and mirabile dictu, I could now write and play drum patterns and tracks in TK-707 with my favorite sound sets in either PAT or SF2 format. With TK-707's
wav2pat utility and Josh Green's fantastic Swami soundfont editor, I can now use any soundfiles on my hard disk as sounds to play via TK-707.
Figure 4: TK-707's Ports window
As to the worth of this endeavor, I've placed three soundfiles online that demonstrate TK-707's output to GUS PAT files (the Midia set), to soundfont patches (the
8mbgmsfx.sf2 set), and to the OPL3 (the standard
drums.o3 set). Check them out, then feel free to tell me which you prefer (I'll be curious to see how many of you vote for the OPL3). For your listening satisfaction, the files are available in MP3 (encoded with LAME) and OGG (encoded with
oggenc) formats, and you can find them at http://linux-sound.org/sounds.