Subject: Stateful volume (Re: Ideas on the audio framework)
To: None <tech-kern@NetBSD.org>
From: TAMURA Kent <kent@NetBSD.org>
List: tech-kern
Date: 12/13/2004 16:36:27
--pgp-sign-Multipart_Mon_Dec_13_16:36:22_2004-1
Content-Type: text/plain; charset=US-ASCII

> > Probably no one opposes making the OSS compat layer stateful.
> > It should be compatible with Linux and FreeBSD.
> 
> That doesn't work.  A mixer can really be stateful if it can make
> sure it intercepts all changes, so it can keep its state.  If some
> other application changes the value behind its back, strange things
> will happen (though, arguably, it will work if someone only uses
> one application for mixer settings.  I, for one, use gkrellm-volume,
> mplayer, mp3blaster and mixerctl all at the same time, depending on
> what I'm doing).

It seems better than the current slider problem :-)

IMO, we should make mixer volumes stateful in the native API,
too.  The current behavior hides hardware differences by halves.
It hides the physical maximum value of a hardware, but does not
hides the physical volume precision and it is difficult for
applications to know correct volume precision.  I like either
exposing the physical maximum value (not 255) to userland or
hiding the physical volume from userland.  The former needs API
changes, and the latter doesn't need API changes.

-- 
TAMURA Kent <kent_2004 at hauN.org> <kent at NetBSD.org>

--pgp-sign-Multipart_Mon_Dec_13_16:36:22_2004-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (NetBSD)

iQEVAwUAQb1Gen7t9398iwLqAQIIAAf+NbInEfIAwivnowkiS1MNvtd+oo5s/YX/
iKJkt7D8G2q362nM8VfwVt875IimoNUXZEDWTNQHVFmSJLAG4LWhbOdz4U9NAdJ9
OR8+qfOCZd/14742wPdxOogqFNX7wPekL9SvYIfRfgsTiFLPhD1vgI6KMeNX50y9
lTIEcRrMJv6D+tAl7ghn9j7hCSNi+C3XaM43KrsGfmIWXC/ukqKork6afRR+2vvI
wrMl7xDXlXzJ1+kGW3gKsimS4d+aPxrYBxjSKPwBxgDVqnlN/JttoybjL0n6K6y7
dDM0Ca36sg9M5but8nSWpjUh6nhrZGhAG8YFGLo2SguxTt8rXrQeJA==
=7Rg2
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Mon_Dec_13_16:36:22_2004-1--