Giving Voice to Linux with ViaVoice - page 3

Open the Pod Bay Door Please, HAL

My sound card is a cheapie--a Creative Labs Ensoniq with the ES1371 chipset. Not a great board, but good enough for my purposes. I use audio so little that I hadn't really bothered to check the specifics of my sound configuration. System sounds worked in KDE and I could play MIDI files from the KDE player. SimCity 3000 worked. What else matters? I'm just not very interested in MP3 or RealAudio right now.

But ViaVoice was more finicky. IBM provides instructions in the documentation for a test that can be performed to validate the sound drivers. This involves using 'dd' to capture a file from the /dev/audio device to a file and then using 'cat' to copy the same file back to the speakers. However, passing this test is not enough. In my case, the sound board was working perfectly but was not operating in 16 bit mode, which ViaVoice requires. When I tried to run the User Guru, it failed at the section where it tries to test the audio support. On the 'playback' test all I got was a sickening GLUG! from the speakers, and from the 'record' test I got nothing but an error message. Not good.

My first stop on the Web was the ViaVoice e-mail list archives, where I learned that many people had problems with audio cards that were only using 8-bit DMA. Under the silly assumption that my es1371.o module had a configuration option for DMA channels, I spent a fruitless hour trying to learn its syntax. Finally, after perusing the source code itself (isn't it nice to be able to do so?) I decided that this module auto-configures DMA and there just isn't any way to force it to use DMA in a particular way.

Since whatever es1371.o was doing wasn't right for ViaVoice, I decided to follow the advice of someone else in the list archives, and try the ALSA drivers. ALSA (Advanced Linux Sound Architecture) is the new API standard for multimedia adapters under Linux. Although I must admit that I am not much of an alpha geek when it comes to multimedia, the ALSA drivers installed easily from source tarball following the instructions that are packaged with the download.

Once ALSA is running, you end up with quite a few new modules loaded. My 'lsmod' output looks like this:

Module                  Size  Used by
snd-mixer-oss           4180   1  (autoclean)
snd-card-ens1371        1868   1
snd-ens1371            10028   0  [snd-card-ens1371]
snd-pcm                31928   0  [snd-ens1371]
snd-timer               9600   0  [snd-pcm]
snd-rawmidi            10008   0  [snd-ens1371]
snd-seq-device          3180   0  [snd-rawmidi]
snd-ac97-codec         23200   0  [snd-ens1371]
snd-mixer              28112   0  [snd-mixer-oss snd-ens1371 snd-ac97-codec]
snd                    37100   1  [snd-mixer-oss snd-card-ens1371 snd-ens1371
    ... snd-pcm snd-timer snd-rawmidi snd-seq-device snd-ac97-codec snd-mixer]
sound                  61080   0  (unused)
soundcore               2788   6  [snd sound]
soundlow                 308   0  [sound]

(irrelevant modules removed for brevity). It looks as if I can drop that 'sound' module from my default load list, but I haven't tested that yet. In any case, and much to my surprise given the complexity of the ALSA code, my sound adapter worked on the first try, without even needing a reboot! There was a section of dependency information to paste into /etc/modules.conf, specifically:

# ALSA portion
alias char-major-116 snd
# OSS/Free portion
alias char-major-14 soundcore

# ALSA portion
alias snd-card-0 snd-card-interwave
alias snd-card-1 snd-card-ens1371
# OSS/Free portion
alias sound-slot-0 snd-card-0
alias sound-slot-1 snd-card-1

# OSS/Free portion - card #1
alias sound-service-0-0 snd-mixer-oss
alias sound-service-0-1 snd-seq-oss
alias sound-service-0-3 snd-pcm-oss
alias sound-service-0-8 snd-seq-oss
alias sound-service-0-12 snd-pcm-oss
# OSS/Free portion - card #2
alias sound-service-1-0 snd-mixer-oss
alias sound-service-1-3 snd-pcm-oss
alias sound-service-1-12 snd-pcm-oss

Of course, your file contents will vary depending on your hardware. The ALSA documentation explains what to put into the file. In my case, all the needed ALSA modules loaded when I did a 'modprobe snd-card-ens1371'. The only downside I can see for the ALSA modules is that they need to be recompiled with every kernel upgrade. That's not a big deal, but you do have to remember to do it. Some of the lines above are needed only if you want OSS/Free emulation, for backward compatibility. I left them in because I had no good reason to remove them. The configuration above works on my machine, and I decided to worry about optimizing it later--first, I wanted to try ViaVoice!

When I started ViaVoice enrollment again, things were even worse than before. This time, instead of an immediate error that said it wasn't getting any audio, I had to wait 30 seconds or so for a rather cryptic timeout error. Back to the list archives! Lo and behold, others had seen the same problem and quickly pointed me to the solution: the microphone must be the 'current recording input' in the mixer panel. Having never really done any sound recording under KDE, I didn't realize that only one input channel feeds the record input. Since I could talk into the microphone and get output from the speakers, I had assumed the microphone channel was enabled. It turns out that you have to use the right mouse button to see a context popup menu on the slider bar for the microphone, then choose 'Rec Source' to make that channel the active recording input. Be sure the microphone channel is not muted! Correct settings look like the accompanying screen shot under KDE 1.2.

That problem solved, I attacked the enrollment process once again. Shazam! Everything was working, and I was soon reading off sample text to adjust the audio level.