Subject: Re: dev/audiobell.c proposal
To: matthew green <>
From: Ben Collver <>
List: tech-kern
Date: 01/13/2004 07:14:22
On Tue, Jan 13, 2004 at 06:39:47PM +1100, matthew green wrote:
>    It seems to me that "neither or both" of these facilities belong in
>    the kernel, and that the choice depends on driver/hardware capability
>    and user preference.
> could be.  i actually stole a bunch of the kernel auconv.c code for
> audio*(1).  it's necessary to be able to output in an arbitrary (ie,
> user defined) format...but i've not needed the aurateconv code yet.
> from what i gather, aurateconv really exists in the kernel to support
> devices that don't support rates that audio(4) says will exist.  eg,
> the default 8000hz setting.
> the main reason i'm not wanting this code in the kernel is really just
> "don't put code in the kernel that can be in userland".
> what do other systems do?

Personally I like the idea of separating the bell from /dev/audio, by
adding a new wscons_event.type, and having something in the userland poll
for it.  There would be the worry of latency, but it could be very
flexible, (ie: it could run a program to send a command to a MIDI robot).

A hacker does for love what others would not do for money.