[MPlayer-dev-eng] [PATCH] forceable software volume control

The Wanderer inverseparadox at comcast.net
Fri Nov 5 11:37:18 CET 2004


Reimar Döffinger wrote:

> Hi,
> 
>>> Hi, this patch allows to force the volume to be changed via
>>> af_volume instead of hardware mixer. This should remove the last
>>> reason for keeping aop (and I _really_ want that outdated crap
>>> out of CVS).
>> 
>> For one thing, this doesn't apply for me (to latest CVS). I don't
>> know why - the patch doesn't look malformed - but 'patch -p0 <
>> ../soft_vol_ctrl.diff' gives seven "Hunk # of # FAILED in
>> <filename" messages over four different files.
> 
> Maybe your aren't using a clean CVS copy? It works for me with
> current CVS...

Well, I had done 'cvs -z3 update -dPA' immediately before trying to
apply; also, 'cvs -z3 diff -u mixer.c' finds no differences. It still
fails, though - checked just moments ago.

The earlier patch, without the man page, applies just fine (at least in
a dry run), though I haven't tested that. I don't know what the problem
could be... although, didn't someone inquire once a few threads back
about carriage return characters in a patch you had sent? I don't see
any in this case, but I didn't see any in that previous one either, and
I'm grasping at straws...

>>> +.B \-softvol-norm <10.0\-200.0>
>>> +Set volume bar position at which volume will not be changed (in percent)
>>> +(default: 90).
>> 
>> I don't think it's good to have the default "unchanged" volume be
>> near the maximum possible. Unless some solid justification for a
>> higher value can be provided, I would prefer to have this default
>> to 50.
> 
> Two points:
 > 1) Consistency
> It is more in line with the hardware mixer (a value of 50 would make
> it behave completely different from hardware mixing)

That is, I'll admit, not a subject on which I know... anything, really.
I don't see how it is true, though, unless I've completely misunderstood
what it is this parameter does - or unless hardware mixers default to
"maximum" or the like, to which I object just on principle.

(Hmmm. The assumption of what this parameter does which was used in
writing that paragraph is completely inconsistent with the assumption of
what it does which was used in the place, below, where I mention
af_volnorm. One of them must be mistaken; which one?)

> 2) Artifacts
> Unless the movie is done very badly, with 50 you will get heavy
> artifacts when turning the volume up fully, so when you want to get
> the maximum working volume you have to try around a lot...

You had made the former part of this argument before, and I don't
consider it to be sufficient. The latter - "ease of use", essentially -
may be a different story, though I'm not sure it justifies reducing the
default maximum possible volume.

> When it is set to 90, you should be able to set the volume to maximum
> without getting problems (I actually thought about making 100 the
> default, but it works very nice for me like this).

...as reference my post over on -users, the ability to adjust the volume
significantly in *either* direction is desirable, and should not be
impossible and/or unworkable with default settings.

60, 70 or even 80 I *might* be able to live with, although I wouldn't be
happy with them (for reasons given in the next paragraph). 100 would
have been absolutely not acceptable.

If I move to adjust volume upwards and see that I'm already within a
smidge of the maximum, I feel like something's wrong, because things
should not assume "high volume" by default; if I move to adjust the
volume downwards and I see the same thing, I get annoyed, because it
feels as if the reason the thing was too loud is because the default is
too high.

(Not to mention that with current af_volnorm, which unless my memory is
playing tricks on me is what this default is by analogue to, the volume
it provides by default is for me too high... by at least a few clicks,
and in some cases considerably more.)

> Anyway, it's just a default... If more people vote for a lower value
> I will consider it, but unless you provide "solid justification" I
> will take my power as the author to set the default as I like it to
> be ;-)

...there's nothing I can do about that, I suppose. It's just that from
my perspective, setting a default anywhere other than "middle ground"
automatically requires justification; IOW, the default for any default
is/"should be" the middle ground (or, for cases where there is no
obvious middle ground, the least common denominator), and hence that
does not require justification. You apparently feel differently, though
I have no comprehension of why...

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

A government exists to serve its citizens, not to control them.




More information about the MPlayer-dev-eng mailing list