Handle cards without mute switch

elboulangero commented 8 years ago

Some audio cards don't have a mute switch, it means that you can't mute it natively with ALSA.

At the moment, PNMixer handle these cards poorly. If your card can't be muted, PNMixer doesn't say anything, doesn't display any hint. Clicking on mute has no effect, that's all.

Discovering if your card can be muted

In order to know if your card can be muted, just launch alsamixer and see if you can mute it.

$ alsamixer

Another way is to use amixer and look for the pswitch capability ("p" stands for playback). Just launch it like that, or invoke it with the name of the mixer you want to know about.

$ amixer

$ amixer get Master
Simple mixer control 'Master',0
  Capabilities: pvolume pvolume-joined pswitch pswitch-joined
  Playback channels: Mono
  Limits: Playback 0 - 42
  Mono: Playback 27 [64%] [-22.50dB] [on]

If pswitch is mentioned in the capabilities line, your card can be muted. If it's not, your card can't be muted.

Improvment 1: display a hint

PNMixer could at least drop a debug line when such a card is encountered.

Furthermore, we should grey out every mute action in the GUI, so that the user clearly sees that his card can't be muted.

Improvment 2: implement a software mute

We could also easily emulate the mute behavior with the volume. Set the volume to zero when user wants to mute, and restore the volume to unmute. It is said that xfce4-mixer implements this behavior (see discussion in #138). I didn't check the code though...

Current workaround

PNMixer allows setting a custom action for middle-click. So you can have a script that takes care of soft muting, and assign it to the middle click.

I wrote such a script, feel free to try it and give feedback, it's available here: https://gitlab.com/elboulangero/asoftmute

hasufell commented 8 years ago

Improvement 1 seems reasonable.

Improvement 2 is a hack. There are various scenarios where this behavior is glitchy and can confuse the user, because the state is pnmixer specific and all the rest of the system doesn't know about it. Only pnmixer. IMO, hacks can be implemented in a fork or maintained as a patch (or like your bash script, which seems fine for that use case). The proper unix way would be to figure out why these cards can't be muted and work with the relevant code bases instead.

foresto commented 8 years ago

Improvement 2 is a hack.

Hack, workaround, or whatever you want to call it, in my experience, it's a pretty common way to implement mute.

There are various scenarios where this behavior is glitchy and can confuse the user, because the state is pnmixer specific and all the rest of the system doesn't know about it. Only pnmixer.

I've seen this approach quite a few places, including various media players and stand-alone volume controls like xfce-mixer. The only thing vaguely resembling a glitch that I've ever seen was that muting the volume in one app and then changing the volume in another app caused the volume to un-mute. It was pretty obvious what was going on, because I could see what I was doing and I could hear the results. It never confused me.

Anyway, I don't want to argue about it. Just offering a different perspective.

hasufell commented 8 years ago

The only thing vaguely resembling a glitch that I've ever seen was that muting the volume in one app and then changing the volume in another app caused the volume to un-mute.

And then there's the scenario where pnmixer gets closed (or crashes even) and the saved state is lost. Or... your xfce-mixer might have a different (or none) restore state saved than pnmixer, then you unmute there and your volume goes something completely unexpected.

nicklan / pnmixer