> 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 ...like running timer
events at a 20k rate for short periods of time as interval timer
events.

> 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
					terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.

------------------------------------------------------------------------------