Ticket #774 (new enhancement)

Opened 2 years ago

Last modified 2 years ago

allow overriding of hardware volume range

Reported by: patrakov@… Owned by: lennart
Milestone: Component: daemon
Keywords: Cc:

Description

I was hit by a bug in mplayer where it set its stream volume to 100%. Since in pulseaudio with flat-volume logic, the device volume is the highest of the stream volumes, this made the sound 30 dB too loud. IMHO, pulseaudio must be much more forgiving.

Also, even though my hardware has a broad range of settable volumes, I don't want it to be exposed in full. Ideally, there should be:

  • some "Setup volume limits..." button in pavucontrol and gnome-volume-control that allows me to pre-define some limits that don't make me deaf and don't make the device completely quiet
  • without using that button, I should be able to adjust the device volume only in the limits set by me earlier
  • 100% (or 0dB) stream volume should refer not to the raw hardware capability, but to the artificial limits set by me at the first step

In other words, let me map unusable or useless volume ranges out, so that they are not entered even accidentally.

Change History

Changed 2 years ago by lennart

  • summary changed from PA allows clients to easily set insanely high volumes to allow overriding of hardware volume range

Hmm, i disagree. If an app wants a certain volume it gets it. This has always been that way, and now is that way still.

The problem is that mplayer and the volume control have the same rights. What you are asking for is that a volume control gets more rights than mplayer, but we really cannot distuingish here. Access control between clients of the same user cannot work.

What we can definitely add though is maybe some udev based system that allows you to override the volume range the hardware supports.

Changed 2 years ago by patrakov@…

Udev-based configuration of volume limits would indeed work for my use case. However, it global in the system and is not user-friendly, and thus some discussion is needed whether it is OK and whether better solutions exist. Note that the desired limits depend on the sensitivity of headphones and thus will be different even for users of the same type of sound cards.

I understand that volume control application and mplayer have the same rights. Thus, within the solution proposed above, it is indeed impossible to protect against malice in mplayer (IOW, strictly enforce policy). After all, a malicious program can access ALSA mixer API directly and thus defeat the limits even if they are set by udev rules. What I want is protection against accidents. And I think that a separate API for setting volume limits (clearly documented as "for use only in mixer applications") would be enough for this protection.

BTW, if you (or one of your friends) have and a fifth-generation iPod, please look how the volume limits UI is organized there.

Note: See TracTickets for help on using tickets.