Subject: Re: Ideas on the audio framework
To: None <tech-kern@NetBSD.org>
From: David Young <firstname.lastname@example.org>
Date: 12/12/2004 13:05:40
On Sun, Dec 12, 2004 at 11:11:23AM +0200, Jukka Marin wrote:
> On Sat, Dec 11, 2004 at 04:45:42PM -0600, David Young wrote:
> > Every volume control is not a slider. Oftentimes the volume control is
> > a a pair of buttons, volume up/down.
> Never seen such an application, but I guess they exist.
*sigh* If you don't know the application space, you should not presume
to suggest an audio API.
> > If a user taps a volume up/down
> > button, he wants for the volume to change instantaneously---it's
> > misleading and annoying to the user if he has to tap the volume control
> > 4-5 times before any change is audible.
> Step of 1/16 of full scale would be audible. What if the hardware allows
> for 256 steps or even more? Is one step audible then?
It doesn't matter. The important thing is that it makes the choice with
knowledge of the hardware capabilities.
> > It seems to me that a kernel
> > volume API that both scales and provides ++volume, --volume is necessarily
> > more complicated than one that lets you adjust the volume between
> > [0, hwmax].
> I don't need to know the size of a hard disk to be able to write a file to
> it. Why doesn't the audio driver hide volume control details?
This is a false analogy if I ever heard one. You *do* need to know the
size of a hard disk to mkfs it. You are quite naive if you think that
it is always possible or desirable to insulate applications from the
> > I think we can afford the overhead for audio applications that want to
> > scale to compute (app_volume * hwmax) / APP_VOLUME_MAX, don't you?
> Give xmmix a try and you'll know why I dislike the way NetBSD works at the
> moment. Besides the fact that I stills strongly believe it is the very
> purpose of the audio drivers to make the various audio hardware look the
> same to the application programs. I still don't know how other unix clones
> work, but I'm 99% certain they do NOT work the way NetBSD does.
Can you state *quite explicitly* what xmmix and/or the NetBSD API does
wrong? If you mean the boneheaded stateful API, I agree with you that
*that* is broken.
David Young OJC Technologies
email@example.com Urbana, IL * (217) 278-3933