[MPlayer-dev-eng] Re: [PATCH] real muting

Alban Bedel albeu at free.fr
Sun Nov 20 18:47:11 CET 2005


On Sun, 20 Nov 2005 14:03:42 +0100
Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> wrote:

> Hi,
> On Sun, Nov 20, 2005 at 01:09:16PM +0100, Alban Bedel wrote:
> > On Sun, 20 Nov 2005 11:17:30 +0100
> > Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> wrote:
> > > the attached patch implements real muting (i.e. the audio device gets
> > > paused).
> > 
> > Having a real muting (when available at the driver/hw level) is a good
> > idea, but pausing the ao to simulate this seems like a really bad idea
> > to me.
> 
> Well, what else is real muting supposed to mean?

When it is supported by the hw, that is the mixer have a "switch"
_independent_ of the volume to turn the channel on/off.

> What you state is IMHO
> just a broken workaround for buggy sound drivers that do not allow the
> volume to be set to 0. For me real muting means no data is passed to the
> ao.

i understood that, i still think it is a very very bad idea considering
mplayer's design and the crap that is sold as soundcard.

> > > It currently disables the "set volume to 0" part, too, this probably
> > > should be an option (suggestions for name + values?).
> > >
> > > Please test it, I'm sure it will cause problems in some cases, e.g.
> > > with -ao alsa the movie makes a short skip forward when muting.
> > 
> > The video is synched on the soundcard, so this method is just asking for
> > troubles. Some ao will keep their buffer when pausing, so the sound
> > migth restart with a rest of what was played before, then brutaly jump
> > to a completly different signal, which may very well produce bad
> > artifacts. If the ao drop the buffer, then it have to be refilled leading
> > to some jump in the video. All in all I bet this will work smoothly
> > (ie like now) in perhaps 1% of the cases.
> 
> There is a reset function that is supposed to clear the buffer, if it's
> not implemented correctily seeking and things like that won't work
> either.

Yep you can always drop the buffer, it nearly guarentee unsmooth playback,
and should solve the audio problem. Should bcs some cards do ugly clicks
when the playback (re)start from a fresh buffer. Yep most of the cheap
sound hw is just crap :(

> Also does it matter if it's completely smooth or not (it should be
> optional anyway)?

Unsmooth playback bcs one mute/unmute, sorry but it just sound ridiculous
to me.

As long as such behaviour is disabled by default why not, but i still
think it's not worth the added complexity. The main loop and all the
sync stuff is already more than complex enouth.

> But there is a reason I asked fo testing...
> 
> > Why not just add a control() to the ao and implement it there ? That way
> > ao that have a real muting (like alsa) could use it, other would just
> > fallback on the current implementation and set the volume to 0 which
> > is more than good enouth in 99% of the cases.
> 
> Where/how does alsa have real muting? The only thing I see is playback
> control, but what exactly does it do? Does it free up the device for use
> by other players? Does it stop the callback functions that pull data and
> consume CPU? I don't think so because that then would cause MPlayer to
> hang instead of mute.

I don't know alsa at all, i was thinking of that patch above where it
seems that one can disable the currently played channel.

> I really don't know what you're thinking of (not
> to mention that in case of a control every ao would have to be changed
> to support it - whereas this method in theory should work for all as is).

Again i'm talking about muting at the mixer level, the dsp continue to
run normally but the (hw) mixer just drop the signal. If it do make
a difference with some cards (like for the person who sent that alsa
patch), then imho the ao should allow setting it and that mean a control.
Wich anyway would be like 2 or 3 lines of clean and simple code, really
no big deal.

Sure a method that work everywhere would be nicer, but what you are
proposing just can't work reliabily with all the broken driver/hw
out there.

	Albeu




More information about the MPlayer-dev-eng mailing list