this morning (more techie junk)

[kragen@pobox.com (Kragen Sitaker)]

I woke up at 10:30 this morning.  (Actually, I woke up at 7:00 and 9:00
too, but I went back to sleep.)

Well, I got ALSA working.  Seems the problem is that I have to modprobe
not just snd-ens1371.o, but also snd-card-ens1371.o.  Having done this,
I tried to play sounds to /dev/audio.  No deal; I had forgotten to
modprobe snd-pcm1-oss.o.  OK, did that; now I could play sounds to
/dev/audio, but nothing came out of the speaker.

I remembered that, according to the documentation, when you first load
the modules, everything is muted.  (Is this a sensible default or what?
The default for the sound driver is to produce no sound.  Huh.)  I am
instructed to use an ALSA mixer to fix this.  Well, there's amixer in
alsa-utils.  (alsa-utils didn't build properly; I guess its configure
script found GTK, but didn't realize it was the wrong version of GTK.)
I messed with amixer for a long time before giving up on understanding
it.

So I try 'alsamixer'.  It outputs the string 'TODO\n' and exits,
which is a highly unusual failure mode for an ncurses application.
(According to the documentation, it's an ncurses-based mixer interface.)
I run ltrace on the executable; it's calling atexit(), then printf(),
then exiting.  Hmm.  I look at the source code.  It says:

#include <stdio.h>

void main(void)
{
        printf("TODO\n");
}

Hmm, guess that clears that up.  There are two other .c files in the
alsamixer directory, called alsamixer_abramo.c and alsamixer_tim.c.
Neither is able to compile, because they reference what appear to be
data types that do not exist.  (They found all their header files OK;
they just couldn't find the data types.)

Hmm, OK.  gamix is out, because it failed to compile.  xamixer2 is the
remaining candidate.  It pops up a window with 9 labeled groups of two
sliders and two more labeled sliders, all set at 0.  I set all the
sliders to their maximum.  Still no joy.  Oh, there's an unlabeled
checkbutton in each group, which is in the unchecked state.  I click all
the checkbuttons.  As I click the last checkbutton, the strains of the
Free Software Song begin to waft (well, OK, blare) from my speakers.  I
turn the master volume down until it stops being distorted.

Good!  I have sound!  Now to do something with it.

I write a small C program to produce an output sine wave and send it to
/dev/audio.  It works, but it sure doesn't sound like a sine wave.
Maybe it's being distorted by mu-law decoding?  Probably.  I look in the
/proc/asound directory for other devices I can write to; I find some in
/proc/asound/dev, pcmC0D0 and pcmC0D1.  Unfortunately, they all sound
the same.

Well, OK -- maybe there are ways to set the sample rate and format?  I
look through the alsa-driver package's documentation.  There's lots of
documentation about how to write a driver, but nothing about the system
call interface.  Well, that's not really true; there is a bit of
documentation on one or two of the files in /proc/asound/card1, and an
injunction not to use the system-call interface -- it's supposed to be
hidden by a library.

That offends me deeply.  I guess I'm just a geek, but I want to be able
to make sounds from Perl scripts without linking in extra grotty C code
from a library, which is a hassle.

alsa-utils includes a program called 'aplay'.  I use 'sox' to convert my
sine-wave to a .wav file and apply 'aplay' to the .wav file.  Magic!  It
sounds like a sine wave now.

strace on aplay says aplay is using no fewer than eight undocumented
ioctls on various sound devices.  Yuck.

I still haven't done anything with bootparamd or portmap.