I have run across some undocumented behaviour in NetBSD's audio driver
which I am not sure whether to classify as a feature or a bug.  It
concerns the way recording or playback is started (or rather, not
started) when the device is used in nonblocking mode.

The way NetBSD's /dev/audio currently works is that if you simply open
the device and then immediately select() on it for reading and/or
writing, nothing will happen.  No playback or recording will start,
and select() will never return.

Similarly, if you open the device for reading, set it to non-blocking
mode, and then attempt to read from it, you will always get
EWOULDBLOCK - no data will ever be read.

This is because recording or playback does not start as soon as the
device is opened, nor does it necessarily start with the first read()
or write() call.  Instead, playback only starts with the first
*blocking* write() call, and recording only starts with the first
*blocking* read() call.  Therefore, you need to perform (at least) a
single blocking read() and write() call to start the recording and
playback processes *before* entering select() or setting the device to
non-blocking mode.

I find this undocumented behaviour rather unintuitive and inconsistent
with that of other devices.  It also effectively makes it impossible to
write a 100% event-driven program - there will always be at least one
blocking I/O call (in practice it will block only very briefly, but
still).

I understand NetBSD's /dev/audio attempts to emulate the SunOS 4 audio
device, but I don't have access to a SunOS 4 system or even the man
page for its audio driver.  Could someone who does please tell me
whether this behaviour is consistent with that of SunOS (in which case
it should be documented) or not (in which case it should be fixed)?
-- 
Andreas Gustafsson, gson@araneus.fi