[MPlayer-dev-eng] [PATCH] Load af_volume when needed

[Reimar Döffinger]

Hi,

>>> This small patch loads af_volume whenever needed. I.e. in the case 
>>> where the ao doesn't support volume, and it isn't already loaded. 
>>> With this patch, ao_macosx has volume support out of the box :)
>>
>> Yes, this would be useful, I just didn't get to do it up to now.
>> First question: wouldn't it make more sense to add this to the 
>> set_volume function? I'd prefer if the volume filter didn't slow down 
>> things for people who don't actually need it. You might have to modify 
>> get_volume to return 90.0 by default when it can't get the volume...
> 
> It seems that, by default, the first call MPlayer does is get_volume(), 
> and that if someone requests something related to volume, loading the 
> filter is fine. In my opinion, the "correct" way of doing this would be 
> to separate the actual getting and setting into a separate function, 
> which tries to load the filter if necessary.

As far as I know the GUI always calls get_volume, whether the user wants 
to change it or not. And af_volume is simply useless when it shouldn't 
change the volume.

> Doesn't af_volume already have a default value? Wouldn't it be a bad 
> idea to duplicate this value somewhere else?

af_volume uses a different scale for setting the volume as the mixer. 
90.0 is the value that get_volume would return as long as set_volume 
hasn't been called. In other words, it should be a "read-only" stub for 
af_volume (to let e.g. the GUI display something useful...)

>> I'd also like to have some status messages, replacing the 
>> MSGTR_NeedAfVolume message like e.g. "inserting af_volume for software 
>> volume control" and "couldn't insert af_volume". 
> 
> Perhaps simply a "Volume control not available" would do, the 
> "inserting" could be restrained for verbose mode?

No, because that is not the point. I want the user to know that
a) we just inserted a filter in the chain (this might cause trouble)
b) he now has volume control, but it is done in software an thus slow.

Greetings,
Reimar Döffinger