On Tue, Dec 07, 2004 at 09:09:45AM +0200, Jukka Marin wrote:
> On Tue, Dec 07, 2004 at 12:51:57AM -0600, David Young wrote:
> > We disagree that the way to fix it is with scaling.  The way to fix it
> > is to tell apps, "I am a volume control.  I am adjustable in the range
> > [0, hwmax].  I will clamp settings greater than hwmax or less than 0."
> > Let the apps decide whether to scale or to provide discrete settings,
> > but do *not* make them represent that there are more settings than there
> > really are, and then conceal the dismal truth from them.
> 
> Why would normal applications NEED that information?  The user adjusts the
> slider until the volume is suitable.  What good does it do to him to see
> how many steps the particular hardware implementation has?  Why would every
> volume control application have to do the same scaling that could just as
> well be done in the audio drivers?  I don't mind being able to query the
> hardware capabilities, but IMO, the application interface should be made
> simple for the application developers.

Every volume control is not a slider.  Oftentimes the volume control is
a a pair of buttons, volume up/down.  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.  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 think we can afford the overhead for audio applications that want to
scale to compute (app_volume * hwmax) / APP_VOLUME_MAX, don't you?

Dave

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