On Sun, 11 Jan 2004, Ben Harris wrote:

> In article <200401110511.AAA08205@Sparkle.Rodents.Montreal.QC.CA> you write:
> >
> >Also needed would be a way to direct console beeps to a specific audio
> >device, or else some other way to direct them to userland for the
> >actual beep generation to be handled there.
>
> For added fun, there can be several wsdisplay/wskbd combinations on a
> machine, and each one needs to be able to send its bells to a different
> place.  This is beginning to sound to me like the right approach would be a
> wsbell device to go alongside wskbd and wsdisplay, being attached to
> wsdisplay in much the same way as wskbd is. [...]

> FWIW, I think that user processes that grab bell output should get (freq,
> length, volume) rather than a waveform, in the same way that TIOCCONS gets
> you characters, not a pixmap of the console screen.

That would limit you to making fairly boring pure tones, like a
hardware keyboard. Imagine if you could make your keyboard beep do
a gong noise, or screaming or moaning sounds. That would be cool.

It sounds like we're cooking up a fairly rich interface, but the only
customer for it need be "wsconsctl" (which already has a "beep" MIB),
or perhaps a "wsbellctl". For each bell the user should be permitted
to choose the device -- builtin (to keyboard), or audio device -- the
type -- builtin, midi, or dac -- and then the parameters for the
various types -- the existing "bell" like interface for the builtin
keyboard beep emulator, or the midi, or a pathname and type for the
dac. All ports and hardware wouldn't have to implement every option,
of course.

I don't think I'd necessarily use an option to send output to a
program (or socket). Some of the daemons mentioned can be configured
to close their device when not actually making noise, so in practice,
it might not be an issue that the keyboard doesn't beep exactly when
an mp3 is playing. If people want really want it, it would just be a
fourth value for the selector, the only paramater being a path to a
file containing arbitrary data.

I guess it would be inefficient and possibly insecure to keep the
source file for the dac or the daemon open; the data could be loaded
to a buffer once, and the pathname retained for reference and display.

Frederick