Neil McRae wrote:
> On Sun, 24 Nov 1996 22:17:43 -0800 (PST) 
>  MLARKIN@CSUPomona.Edu wrote:
> 
>> 2. The realaudio Solaris/SunOS player doesn't work, complains about "Error
>>    opening audio device"
> 
> Ick, email Progressive, I'm well pissed of with them not releasing a driver
> for netbsd.

*chuckle*  You've gotta be kidding, Neil, like Progressive really cares about
an O/S with no market share ... bad enough they release RA 3.0 for Windoze
and Macs before any UNIX port appears.  But I'll save my standard "What?  Use
established Internet standards like RTP?  You've got to be joking" rant for
some other time ...

Anyway, the reason Real Audio doesn't work (at least, the first reason) is
because we don't have a "/dev/audioctl" device.

If you look at a SunOS audio(4), it seems on the surface that it should be
relatively easy to implement:

  Audio Control Pseudo-Device
     It is sometimes convenient to have an application, such as a
     volume  control panel, modify certain characteristics of the
     audio device while it is being used by an unrelated process.
     The  /dev/audioctl  pseudo-device  is provided for this pur-
     pose.  Any number of processes may open /dev/audioctl simul-
     taneously.   However,  read()  and  write() system calls are
     ignored   by   /dev/audioctl.    The    AUDIO_GETINFO    and
     AUDIO_SETINFO  ioctl commands may be issued to /dev/audioctl
     to determine the status or alter the behavior of /dev/audio.

I'm not sure, however, how easy it is to do in practice.  (Especially if you
read the asynchronous notification capabilities of the audioctl pseudo-device
in the "Audio Status Change Notification" section of audio(4) that immediately
succeeds the above.)

The SunOS audio driver itself is a STREAMS driver, and when it is opened the
routines check to see if it was opened via a "clone open" (see the SunOS 4.1.x
<sys/stream.h>).  It might be simpler for NetBSD to just emulate the same
device characteristics (i.e., same major number, but minor number 1; use
the minor number to check to see if the control device was opened, as opposed
to the SunOS hack of seeing if the CLONEOPEN bit is set), and simply implement
the above characteristics (i.e., allow multiple processes to open the audio
device and do ioctl()'s without letting them read() or write() the device).

[A few minutes and a few e-mails later]  Then again, I've just read Jesper
Nilsson's missive about /dev/mixer, and maybe that's where all this stuff
should be implemented, and "/dev/audioctl" could be a symlink to "/dev/mixer".

Comments?

	- Greg