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
hardware capabilities.

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

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933