Giving Voice to Linux with ViaVoice
I'm sorry, Dave. I'm afraid I can't do that
Scott Courtney
Tuesday, December 26, 2000 11:00:42 AM
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.
Next: Good morning, Dr. Chandra. I'm ready for my first lesson. »
