Subject: Re: Ideas on the audio framework
To: None <tech-kern@NetBSD.org>
From: David Young <firstname.lastname@example.org>
Date: 12/11/2004 16:45:42
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
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?
David Young OJC Technologies
email@example.com Urbana, IL * (217) 278-3933