Subject: Re: PC-speaker driver working, now what ???
To: S|ren Schmidt <email@example.com>
From: A Wizard of Earth C <firstname.lastname@example.org>
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
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
> 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...
> I would like some input on this, before I decide how it will be
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.
Any opinions in this posting are my own and not those of my present
or previous employers.