Mike Long writes:
> 
> >Date: Mon, 15 Jul 1996 06:58:32 -0400
> >From: "Nathaniel D. Daw" <ndd2@columbia.edu>
> >
> >I am in the midst of putting together a shopping list for a new
> >computer, and I had several questions about hardware compatibility.
> >
> >1) There was some indication on this list that the Soundblaster 16 might
> >be able to do full-duplex: real, simultaneous playback and record using
> >two DMA channels. It's cheaper than the GUS, and if this is possible
> >(even if the NetBSD drivers don't yet support it) I would go for it. Has
> >it been confirmed?
> 
> The SB16 is full-duplex.  Only one direction can be 16-bit; the other
> must be 8-bit.

I am working on the SB16 driver, and plan to add full-duplex in "time".
Specifically, it looks like it will take a long time.  ;-)

I have researched the needed changes and am actually in the "writing code"
stage, but I would not make your hardware purchase decision on the
assumption that there will be a good full-duplex driver out within a month.
Three months is a more realistic expectation.

While I'm on the subject, I was pondering something today after being
frustrated by trying to wedge the SB16 mixer changes into the current
structure.  The /dev/audio interface is modeled after the SunOS version.
This interface seems to provide a pretty small subset of what the SB16
mixer can handle.  This, coupled with the fact that I will need to write
entirely different interrupt handlers to do autoinit DMA makes me wonder
if it would be a worse sin to wedge the code into the current sb* driver,
or make a new device "sbst" for SB16 cards...?  It would use the /dev/audio
interface, and have the extended functionality manipulated through the mixer
ioctls, as the other drivers do, but would have the benefit of having no
"if (one card) else (the other) case (whateverversion), etc...".  Thoughts?
The basic problem is that almost *everything* in the mixer is handled
through different port locations, etc, and the DMA will even be different.
Which is a worse hack?

Mark