Hey folks --

Looking at some of the Linux OSS code, it seems that they default the
audio device to full-duplex mode if the device was opened read/write. We
currently don't do this (it's commented out in sys/dev/audio.c):

        sc->sc_full_duplex = 0;
/* doesn't always work right on SB.
                (flags & (FWRITE|FREAD)) == (FWRITE|FREAD) &&
                (hw->get_props(sc->hw_hdl) & AUDIO_PROP_FULLDUPLEX);
*/

It's strange; OSS has a 'set full duplex' ioctl, which needs to be
implemented by the low-level hardware driver.. yet, it appears to be
unsupported by many of the drivers which claim to support full-duplex
operation. Anyway, it looks as if the ioctl isn't required, since they
set the device to full-duplex if the card supports it and if the device
is opened read/write.

Skype is one such application that doesn't bother calling the (seeming
unsupported) 'set full duplex' ioctl; instead, it opens /dev/dsp
read/write and assumes that OSS is going to put the device in
full-duplex mode for it (see misc/30044). We fail to properly emulate
the OSS behaviour here.

FYI: CVS says that this behaviour was changed in revision 1.68 of
audio.c, over 7 1/2 years ago: "Make sure audio device starts in
half-duplex mode and document the fact."

Anyway, my test was to launch skype, and call my cell phone. After
answering, I checked audioctl and it confirmed that the device was still
in half-duplex mode. I spoke on my cell phone, and could hear myself on
the PC, but when I spoke into the PC I couldn't hear myself on the
phone. As soon as I set full-duplex mode with audioctl, everything
worked fine.

So what I'm proposing is to change this silly default in the NetBSD
audio subsystem to match the OSS behaviour. It seems strange to default
a device to half-duplex mode if full-duplex is supported and the device
was opened read/write. Surely if the caller was opening the audio device
read/write, they were doing so for a reason.

Any objections to this change?

Cheers,
Jared