> > 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.

Yes, I have thought of this also. But the RTC is more limited in
that it only allows intervals that is the 32768 Khz clock
diveded by some power of two, that could give us a timer of 64
or 128 Hz, this is a somewhat "unusual" HZ value, but I think
taht should be OK. This second thing is that the RTC interrupt
is at priority 2, that is after TIMER1, keyboard then RTC. That
could be rearranged though, leaving TIMER1 and keyboard at the
lowest priority.....

I'll try this out, and put in an function interface to the
TIMER? stuff, so it can be more genarally used. Any comments ??
 
> > 2. Should it be a device or a pseudo-device.
> 
> /dev/audio should be a real device.

I aggree.
 
> > 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).

When (if) the above scheme gets implemented they can happily
coexist (with some changes to the old spkr.c 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.
 
Well it /dev/audio seems to be the way to go...

> > 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.

This has to be considered of cause. We could call this interface
/dev/pcaudio an d then link as nessesary.

> (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.

This is kind of what is does now :-)

> 
> 
> 					Terry Lambert
> 					terry@cs.weber.edu
> ---
> Any opinions in this posting are my own and not those of my present
> or previous employers.


                                           Soeren Schmidt
                                           sos@login.dkuug.dk


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