Subject: Re: PC-speaker driver working, now what ???
To: S|ren Schmidt <>
From: A Wizard of Earth C <>
List: current-users
Date: 01/06/1994 13:22:41
> So I now have the driver that uses the built in speaker as an
> "real" audio device. It plays raw and .au format soundfiles with
> reasonable sound quality.
> Now there are some questions that needs be adressed before it can be
> put easily into the kernel.
> 1. We need a method that allows one to "steal" an interrupt
>    vector, and restore it again. 
>    This is because I need to reprogram TIMER1 to give me ~20000
>    interrupts pr sec. for the player, but ONLY when it plays as
>    this imposes _some_ load on the system...

Cranking the timer rate intermittently while the timer is used for
other things really isn't practical -- you'd pretty much need to crank
it all the time unless you pushed the other activity elsewhere (onto
another timer).

This is pretty much the timer code rewrite I occasionally suggest.
Since the internal timer has a much higher resoloution than the RTC
timers, but the resoloution at which it is used is lower than the RTC
timers, I once again suggest moving the main clock off to an RTC to
free up the internal time for one-shot use running timer
events at a 20k rate for short periods of time as interval timer

> 2. Should it be a device or a pseudo-device.

/dev/audio should be a real device.

> 3. If it should co-exist with the old speaker driver there is
>    some handshaking about the timers nessesary.

Actually, the old speaker driver could probably be a consumer of the
new driver (if you are talking about the note-playing driver).

> 4. We need a name for this driver, speaker is allready taken :-(

/dev/audio seems best.

> 5. What kind of device interface ? /dev/audio sun style or
>    something more esoteric...

/dev/audio, again.

> I would like some input on this, before I decide how it will be
> done.

The only thing you haven't asked that I think needs to be considered is
multiple audio interfaces being in the same machine contending with
each other for device names; the two ways to handle this are:

(1)	A config issue; you make /dev/audio0, /dev/audio1, ... and then
	symbolic link (based on install time configuration) /dev/audio
	to whatever is the primary device.

(2)	Have just one /dev/audio allowed, but runtime load the device
	driver itself (giving preference to a real sound card).  This
	technology is in NetBSD and nearly in FreeBSD for production
	use like this.

					Terry Lambert
Any opinions in this posting are my own and not those of my present
or previous employers.