On Wed, Oct 08, 2003 at 10:29:28AM +0100, David Brownlee wrote:
> On Wed, 8 Oct 2003, Robert Elz wrote:
> 
> >     Date:        Tue, 7 Oct 2003 23:29:37 +0200
> >     From:        Quentin Garnier <netbsd@quatriemek.com>
> >     Message-ID:  <20031007232937.0005f07f.netbsd@quatriemek.com>
> >
> >   | 4. Adding the Linux and FreeBSD scheme to our mixer driver. This might be
> >   | the best (err, less worse) solution (although Lennart and David might
> >   | simply not like it ;), but this is not necessarily easy given our current
> >   | architecture.
> >
> > This is the right way to do it.   One of the roles of the OS is to hide
> > dumb hardware design issues from the majority of applications that don't
> > want to, and don't need to, understand any of this stuff.
> >
> > The real hardware granularity and range ought be available for those
> > applications that really want to know - but nothing should be forced to
> > care about that if it doesn't want to.
> 
> 	Would this mean that outputs.master would not display the true
> 	granularity? eg: currently on a card here setting one up from
> 	239 results in the (true) value of 247 being set rather than
> 	a fake '240'.

Mostly, yes. Because outputs.master would never know the real hardware
value. Although the stepping behaviour respecting the delta can be kept,
but in that case we have to make damn sure we *round* the value instead
of truncating them.

We could actually provide the to ways of accessing the value, and that's
mostly what solution 3. is about.

> 	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.

Quentin Garnier.