[MPlayer-dev-eng] [PATCH] Mac OS X updates for darwinfixlib, libmpeg2 and ao_macosx

[D Richard Felker III]

On Wed, Jun 11, 2003 at 11:54:42PM +0200, Dan Christiansen wrote:
> On Tuesday, June 10, 2003, at 05:21 AM, D Richard Felker III wrote:
> 
> >On Tue, Jun 10, 2003 at 12:59:09AM +0200, Dan Christiansen wrote:
> >>Hi,
> >>
> >>Attached are three patches for MPlayer :)
> >>
> >>mplayer-makefile.diff:
> >>
> >>I've found it rather annoying that MPlayer would run ranlib on all
> >>libraries even though only one of them where changed. It meant that
> >>mplayer and mencoder would be relinked when running "make install" -
> >>very annoying indeed. This patch will change the behaviour from 
> >>running
> >>ranlib on all libraries prior to linking to processing libraries one 
> >>at
> >>a time after their compilation.
> >
> >If this really happens, it should be fixed, but it never happens to
> >me. Nothing should have changed when you run make install...
> 
> I'm not quite sure why it happens, but it is what happens, and it's 
> been happening as long as I have been compiling MPlayer. It may be due 
> to ranlib touching the libraries and altering their modification date, 
> so make will believe that they were altered since the linking.
> 
> I just discovered that the way I do it in the patch isn't the best. 
> I'll send a better one later. (If making in a directory, and then in 
> mplayer, ranlib doesn't get run.) Anyway, the reason it happens to you 
> is probably that you don't use Darwin, and therefore darwinfixlib has 
> no effect on you computer ;)

Ah, ok, makes sense. BTW is there a way to clean this up without
adding lots of junk to individual makefiles? The whole "darwinfixlib"
thing seemed rather ugly to me from the beginning.

> >Didn't we already go over the fact that volume emulation through
> >software does NOT belong in ao drivers?? Use pl_volume for the time
> >being (-aop list=volume) or fix mplayer to be able to control
> >af_volume interactively. But don't add ugly hacks like this.
> 
> I'm quite surprised that you call this an "ugly hack". Yes, it may not 
> be the optimal way of doing this, but I wouldn't call it an ugly hack; 
> it could be a _lot_ worse ;)
> 
> I do understand your need for consistency in the design for MPlayer, 
> but there are some disadvantages to using pl_volume. First of all, in 
> it's current incarnation, it doesn't support float. Second, it adds IMO 
> unnecessary features like clipping. Third, it applies the same volume 
> to left and right, so it can't handle balance. Fourth, I suspect that 
> the volume control that the other AOs use is emulated too, it's just 
> that the library handles it.

Huh? The main other AO's are oss, alsa, and sdl. I'm not sure about
sdl, but I know the others don't emulate it.

> Of course, if you really believe that not having volume emulation in 
> _one_ audio output module is so important it justifies all these 
> changes and the missing features, I'll do it (eventually). IMHO it's 
> not worth it.

I believe that putting in hacks like this creates more code to be
maintained, debugged, and downloaded. A few months down the line when
we have real software volume support with af_volume controllable at
runtime, it's going to be silly to also have it in specific ao
drivers.

If you really care about volume control so much, could you please
submit a clean patch that lets the user control af_volume through the
normal volume controls when it's active?

Rich