On Wed, 8 Oct 2003 cube@cubidou.net wrote:

> > 	If the existing OSS or similar interface specified a behaviour we
> > 	should match it, but if that behaviour is broken then we should
> > 	not use it in a native interface.
>
> OSS programmer's guide says:
>
> 	Most mixers have anywhere from 3 to 8 bits of accuracy for
> 	controlling the volume at the hardware level. The OSS driver
> 	scales between the local (0-100) and hardware defined volume.
> 	Since this scaling is not exact, the application should be
> 	careful when using the volume returned by the ioctl calls. If
> 	the application writes the volume and then reads it back, the
> 	returned volume is usually slightly different (smaller) than
> 	the requested one. If the write-read sequence is repeated
> 	several times, the volume level slides to zero even if the
> 	application makes no changes itself. It is recommended,
> 	therefore, that the application reads the volume just during
> 	initialization and ignores the volume returned later.
>
> which doesn't seem to match what Linux and FreeBSD do, but rather what
> NetBSD does, except we're not dumb enough to not provide a way to know
> granularity.
>
> So, OSS "specification" is not helpful here.

	Hmm - that was _probably_ intended to refer to converting
	between the 1-100 in the API to an internal 8bit representation,
	at least that is probably what it effectively refers to in
	the Linux and FreeBSD implementations.

	Whether we comply with the literal definition depends on
	what is regarded as 'smaller'. Certainly on hardware with
	3 bits of accuracy for volume we do not.

	So... for real OSS compatability we _must_ have a stateful
	volume setting which does not reflect the true hardware
	value ... bugger.

-- 
		David/absolute          -- www.netbsd.org: No hype required --