Subject: Re: dev/audiobell.c proposal
To: matthew green <email@example.com>
From: Ben Collver <firstname.lastname@example.org>
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.