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

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