Date:        Wed, 8 Oct 2003 10:29:28 +0100 (BST)
    From:        David Brownlee <abs@netbsd.org>
    Message-ID:  <Pine.NEB.4.58.0310081024140.451@iris.absd.org>

  | 	Would this mean that outputs.master would not display the true
  | 	granularity?

Negative questions ...  I believe that is correct, if I parse it
accurately - it would display whatever it was set to.

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

I consider that ("currently") broken.   If I set 240, 240 is what I want.
If that generates the exact same output as 239 then that's my problem (and
usually I'll just keep increasing it till I get what I want).

Consider the effect if I do

	mixerctl -w outputs.master=$(expr $(mixerctl outputs.master$) + 2$)
	mixerctl -w outputs.master=$(expr $(mixerctl outputs.master$) - 1$)
	mixerctl -w outputs.master=$(expr $(mixerctl outputs.master$) - 1$)

If I don't get back the value I started with, to me, that is broken
(and for all similar variations - arithmetic should be commutative
and associative).

On my system, which is not quite current, it works - but because the + 2
generates the same value as + 1 would, the first -1 makes no change at
all, and the second -1 reverts to the original value.   I consider that
broken as well... (but I believe this is what changed in -current
recently).

[Aside: ignore the fact that this doesn't work because the output from
mixerctl isn't a simple integer that expr can add or subtract a constant
from - I think you can see what I mean.]

If my application knows that real hardware tends to have coarser
jumps than the basic API makes it appear, then it can ask the driver
what that granualarity is, and then if it wants to jump from 239 to 247
because the user said "more", and it knows this is the smallest possible
"more" that really is more, then it can simply set 247.

A mixer application I can believe would want to go to that trouble, a
CD player application (or a game that makes noise) most likely wouldn't
relying upon the user to keep adjusting things until satisfied (from a
human perspective, users are quite used to trivial changes to the volume
knob, or balance contol, producing no noticeable effect - that's what
happens on real equipment).

I have no problem with an alternative (less often used, I'd assume)
way of fetching the values, that returns the true hardware settings.

kre