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

[The Wanderer]

Oded Shimon wrote:

> On Friday 05 November 2004 18:23, The Wanderer wrote:
> 
>> No, I've used the command I gave more than once in the past to
>> compare files against CVS (including for creation of patches), and
>> it's worked just fine. I've never had to specify a revision with
>> MPlayer, and would be considerably surprised if it were suddenly
>> necessary now.
> 
> I think you might still be a bit confused, or I am - CVS remembers
> when you downloaded your file from CVS. And the server remembers all
> the files from every time. So when you do a CVS 'diff', it doesn't
> compare with the most recent MPlayer, it compares with the files you
> _originally_ downloaded, so you can see ONLY the changes you made,
> and not the changes made in the CVS. This is its behavior at least
> for me...

Well, this is not the behaviour I expected - I expected it to compare
against the most recent revision in CVS, unless otherwise specified. It
isn't relevant, however, because the files had just been updated from
CVS and hence would have been identical to those in the most recent
revision, before applying the patch.

>> Just tested again, with a file I've modified myself towards the
>> next patches in the printf --> mp_msg conversion, and the command I
>> quoted above works just fine.
> 
> Of course it did, it showed you the changes YOU made, not the changes
> made to the CVS!

Of course. My point is that if any changes *had* been made to the local
file in the case at hand (the one where I'm attempting to apply the
current patch), they would have shown up in a comparable diff - and such
a diff reported no differences, hence the file must have been unchanged.

>> Oh, wait - did you mean "modify manually" as in "edit by hand
>> rather than by applying a patch"? If so, then you misinterpreted my
>> comment above; "no differences" is *without* having applied the
>> patch. (Also, comparing against another local source tree which is
>> identical to CVS likewise reports no changes.)
> 
> No, I meant ANY changes made to your files which made it even
> different by hand.

Right, that's what I thought you meant at first, but what you were
saying didn't make sense that way. The point was that if my local copy
of mixer.c were different from the one in CVS, then the 'cvs diff'
command should have reported those differences; it did not report any,
so presumably there were none.

> Doing 'touch somefile.c' prevent CVS from even updating it again
> unless you force it to. Again, at least for me.

Not behaviour I knew about (and I don't know how one would "force" CVS
to update such a file, short of deleting the thing and having it be
re-fetched), but oh well. I'm not sure offhand how such behaviour would
be desirable, but...

>> Yes, and if there are no conflicts between any changes I made and
>> the ones in the updated version, I want to keep my changes. If
>> there are conflicts, then the file winds up in a non-compilable
>> state, and I go in and make whatever edits are necessary to bring
>> it into shape. (Usually that consists of removing the record of my
>> own changes, but sometimes I want to either keep them anyway or
>> combine them with the updated code.)
> 
> Usually when I want to update and keep my changes, I do this:
> cvs -q -z3 diff -u > ../mp.patch
> cvs -z3 update -C
> patch --dry-run -p0 < ../mp.patch
> 
> That way I get the up-to-date files, with my changes, and I can see
> and fix if anything has changed that breaks my patches.

Seems like more trouble than it's worth in most cases, to me. Possibly
not when updating one's working tree, but... eh. I have some argument
which might apply here, but my brain feels like burnished copper, which
is a decidedly odd simile and doesn't really convey much information but
is more accurate than "feels like cotton" right now.

>> The counter-argument to that, which he made recently on the -users
>> list, is that raising the volume by more than about 10% causes
>> extremely audible artifacting. I don't know if that's true - I
>> certainly don't remember encountering such artifacting myself in
>> all cases before reaching *much* higher volumes - but if so it does
>> present a fairly good case for not going past that range by
>> default.
> 
> I didn't notice such defects. lemme try again... I managed to get to
> about 150% without noticeable defects. after that it becomes pretty
> noticeable and after 200% it becomes unbearable.

That's more in line with my own experience, though I don't claim that my
experience is anywhere near universal. Having just checked myself, at
150% (achieved using the volume plugin, not the volume filter) I can
indeed hear some artifacting (in one file tested but not in another),
but not more than could be attributed to the audio itself containing
artifacts which are more noticeable at higher volumes; at 180% I can
hear minor artifacts even in the file which had none at 150%, but that's
certainly well over 110%.

(It's possible that the results might change significantly when using
the volume filter, which I have not yet successfully applied (although
if this keeps up for very long I may go so far as to apply it by hand);
in that case, however, the lack of comparable volume-increasing
capabilities would constitute another argument against the volume filter
being an adequate replacement for the volume plugin.)

> I personally have my hardware mixer always set to ~40% (VERY low, my
> hardware mixer is weird, 90% is like half), and my speakers always on
> max volume (the reason for this is an effective automated alarm
> clock...), using those settings I got to about 300% with barely
> noticing the defects.

300% is not possible with the volume plugin, but having set my "main"
volume to 50%, at 255% I can still hear extensive artifacts; they're
much quieter than before, but no less severe. (For the record, I
habitually have my "main" volume set to 84%, for arbitrary reasons
having to do with the fact that most things' default volume sounds about
right with that setting.)

>> On a complete tangent, is there any particular reason why your
>> posts specify the use of a Hebrew encoding scheme (ISO-8859-8-I)? I
>> expect that sort of thing in cases where the text contains
>> non-ASCII characters (i.e., posts with Japanese characters and the
>> like, which I see not infrequently), but since you have so far been
>> posting entirely in the Roman alphabet I'm wondering if there's
>> something going on.
> 
> Heh, I didn't know it did that... I guess it grabbed it from system's
> language settings... I changed it, I think.. is it better now?

Nope, not a bit. The problem is in a particular mail header, to wit:

==
Content-Type: text/plain;
   charset="iso-8859-8-i"
==

I don't know where this sort of thing is configured, but in comparison,
the same header from one of my own posts reads:

==
Content-Type: text/plain; charset=us-ascii; format=flowed
==

I've just poked around a bit, but I don't see where to configure that
setting in my own mail program (Mozilla... yes, I know, I really ought
to get a better mail client), so I don't know what more to suggest.

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