Subject: Re: Ideas on the audio framework
To: Eric Haszlakiewicz <email@example.com>
From: None <firstname.lastname@example.org>
Date: 12/13/2004 06:04:19
Content-Type: text/plain; charset=us-ascii
On Sun, Dec 12, 2004 at 08:44:17PM -0600, Eric Haszlakiewicz wrote:
> On Sun, Dec 12, 2004 at 04:19:22PM -0600, David Young wrote:
> > We are 95% agreed. The 5% where we disagree is whether or not the
> > volume resolution is a limitation that can be hidden. If you hide that
> > information, you don't make the application's job any easier, and you
> > foreclose certain possibilities.
> Actually, you _do_ make the application's job easier because it
> doesn't need to keep state.=20
That's not true. An application doing up/down operations should never
keep state (either there is an up/down API, or it has to re-read the
mixer control level before doing it), and to display a slider it has to
(unless it can get notifications of level changes). This not dependent
on the API, but rather on the fact that two processes can manipulate a
mixer level at the same time.
> What are these "certain possibilities" that you are talking about?
> As long as it is possible for an app to figure out what a meaningful
> volume step is, I don't see what keeping state in the kernel could
> prevent you from doing. It currently _is_ possible to figure out
> the hardware step: mixerctl -w outputs.master++ works. I don't think
> anyone is proposing removing that feature.
> Things that I can think an app would want to do with volume:
> set volume to level X
> increase/decrease the volume by one step
> increase/decrease the volumn by one meaningful step
> All of these are possible with a stateful volume control.
> What else can you do with a volume knob?
You're missing the point here. The NetBSD API allows all 3 actions.
OSS API doesn't allow action 3, so OSS application have no way to
figure out what a meaningful step is.
And I agree with David on that point: the "meaningful step" is an
important information, otherwise applications (and it's the case of
all OSS application, whatever the OS is) don't necessarily raise
the volume when you ask them for it. The value is changed, but it
does nothing to the hardware. OSS API is inherently broken in
So yes, we _could_ rewrite all pkgsrc applications to use the NetBSD
API on NetBSD. But no one will do that.
Quentin Garnier - email@example.com - cube@NetBSD.org
"Commala-come-five! / Even when the shadows rise!
To see the world and walk the world / Makes ya glad to be alive."
Susannah's Song, The Dark Tower VI, Stephen King, 2004.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)
-----END PGP SIGNATURE-----