On Wed, 8 Oct 2003, Robert Elz wrote:

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

	That is displaying what the software value is, not what the
	hardware was...

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

	Hmm - I think we have opposite view of what constitutes 'broken'
	default behaviour, but both agree the other behaviour can be
	useful in certain circumstances.

	I personally want an app to indicate what the real hardware is
	set to, and when I say 'up one notch' that is exactly what
	I want, rather than 'up, up, up, up, up(makes a difference)'.

	The granularity definitely needs to be exposed, whatever solution
	is used.

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