Following up to my change in the ac97 mixer code, I took a closer look at
the ways of working around the issue and what is done by other systems.

Both Linux (in the OSS layer) and FreeBSD have an intermediate layer in
the mixer code that makes every possible value available to the userland.

Here's what happen in Linux and FreeBSD:

mixer_ioctl_write(mixer, channel, newvalue):
	mixer.write_to_hardware(channel, newvalue)
	mixer.values[channel] = newvalue
	return

mixer_ioctl_read(mixer, channel):
	return mixer.values[channel]

In NetBSD, we do this:

mixer_ioctl_write(mixer, channel, newvalue):
	mixer.write_to_hardware(channel, newvalue)
	return

mixer_ioctl_read(mixer, channel):
	return mixer.read_from_hardware(channel)

Having direct access to the hardware from userland seems nice, but it has
the side-effect of exposing the applications to the hardware limitations,
like the reduced actual set of possible values.

In ALSA (you know, with their 1500+ lines "hello, world!" mixer example)
and NetBSD, you can get enough information from the device to know about
possible values, but this is not possible with the OSS API. Thus,
mp3blaster's (and others) behaviour is perfectly correct WRT OSS, but
leads to a bug.

I have thought of several solutions for that issue, none of which being
nowhere near from good:

1. Back out the change completely, and screw OSS apps! (Native
applications that make assumptions about mixer granularity are simply
broken.)

2. Leave the change as it is, possibly extending it to other non-ac97
hardware. There are several issues with that code, besides the fact that
David Young and Lennart Augustsson simply don't like stateful mixers. For
example, consider this:

	% for ((i=7;i<10;i++)) do mixerctl -w outputs.master=$i; done
	outputs.master: 15,15 -> 7,7
	outputs.master: 7,7 -> 15,15
	outputs.master: 15,15 -> 7,7

The result is not really satisfactory. Native applications will not be
affacted as long as they don't allow setting arbitrary values, conforming
themselves to the granularity of the mixer. OSS applications can be
affected, though.

3. Adding the Linux and FreeBSD scheme to the OSS compatibility layer.
This is not possible in libossaudio, thus would need an overhaul of that
compatibility implementation.

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.

Before I start anything, I'd like to have some opinions. My code in ac97.c
is not really harmful, so there's no real hurry.

I'd appreciate a 5., too :)

-- 
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"Feels like I'm fiddling while Rome is burning down.
Should I lay my fiddle down and take a rifle from the ground ?"
Leigh Nash/Sixpence None The Richer, Paralyzed, Divine Discontents, 2002.