In article <v6bue1irni.fsf@kechara.flame.org> Michael Graff wrote:
> > I've noticed that sbdsp.c has had SB16 support inside #ifdef notyet
> > blocks for quite a while now... is work still being done on it? I
>
> ... I too have a choppy SB16.

So do I, and lots of other people.  And I'm not talking about 16-bit
stereo sound - even ordinary 8-bit, 8 kHz .au files sound awful.

My own theory as to why the driver doesn't work properly is that it
uses a single-buffered mode, where the card issues one interrupt per
bufferful of data played (SB_DSP_WDMA = command code 0x14).

All the other SoundBlaster drivers I have looked at use an
"auto-initialize" mode (e.g., command code 0x1C), where the card issues
two interrupts per bufferful of data, allowing the driver to fill one
half of the DMA buffer while the other half is being played.  This
increases the allowable interrupt latency by orders of magnitude.

I suspect the single-buffered mode may not ever have been intended 
for continuous playback use.  The code examples in
oak.oakland.edu:/SimTel/msdos/sound/sblast09.zip seem to use it only
for playing short sounds that fit in a single DMA buffer - all
continuous playback examples use an auto-initialize mode.

Mark Willey <willeyma@expert.cc.purdue.edu> has been working on an
alternative SB16 driver from NetBSD, but I don't know its current
status.  See http://purcell.ecn.purdue.edu/~willey/projects/sb16/.
-- 
Andreas Gustafsson, gson@araneus.fi