player/command: deprecate ao-volume and ao-mute#17704
player/command: deprecate ao-volume and ao-mute#17704llyyr wants to merge 1 commit intompv-player:masterfrom
Conversation
These properties were mostly only useful before the removal of --softvol=no. At present, mpv has its own volume mixer and never touches the audio server volume at all. There's no reason for mpv to provide these properties, if users wish to change the audio server volume, it's trivial to do so in a Lua/Javascript script. Moreover, ao-volume presents the audio server volume as-is, meaning without any conversion or normalization. As such, the meaning of the value changes depending on the audio server in use or the configuration of the audio server. There's no correct way for mpv to do this normalization. This kind of functionality is better suited for a Lua/Javascript script where the user can normalize the values to their preferred scale, and not bloat mpv with pointless properties that are confusing and not useful.
llyyr
force-pushed
the
deprecate-ao-properties
branch
from
c3ef7d5 to
e4cd528
Compare
|
oh, now i see your point!
instead:
p.s. deprecate |
|
I never use mpv internal soft volume.
Changing volume using GUI volume controls for application volume should also be able to control mpv volume. This works fine with pulse. I have not tested with pipewire |
|
I'm against this, this property is quintessential towards making mpvOS. Some users may prefer ao-volume instead of softvol of mpv mixer. |
|
@llyyr are we talking about the same thing at all? do you copy that under PA and PW it's NOT the system volume anymore (unless ALSA), but per-process/audio-stream volume? tests
and "your soundcard works perfectly!" © ... moreso, p.s. #17703 reverting cubic scale for as expectedso, i suppose this IS what everyone EXPECTS and probably matches the docs! 😆 |
This is a bad argument. It's trivial to do a lot of things if you shell out to some helper tool (e.g. clipboard), yet many things are very useful to have inside mpv. |
|
on macos these offer zero latency volume changes, while internal volume, speed, etc have non trivial latency bound by audio buffer size. should not be removed. |
This can be done with watch later
This can be done with auto profiles and watch later as well
This is an argument against reverting softvol=no removal, not against this PR. This PR is just doing what wm4 would've wanted.
The reason we added clipboard to mpv was because there was a proposed internal user for it, that being writing images directly to clipboard. There are no internal users for ao-volume or ao-mute. People also wish mpv could directly change their display modeset, but we don't have in mpv core do we? A script is a perfect match for this use case, and I don't mind writing one myself and maintaining it in the TOOLS subdir if it would help push this forward. I could say the same thing you did to argue in favor of including any and everything in mpv core. In fact, "thing should be a script because it's easier to maintain" was the main argument thrown around against having #15845. Which one is it?
Default buffer shouldn't be so huge that it has non trivial perceivable latency, --audio-buffer is only 200ms and can likely be smaller without issues. |
This is not possible for avfoundation: #11955 (comment) And the purposed solution by the feature author is to use ao-volume/ao-mute: |
The feature author states that it is merely a "simple workaround". The proposed solution is the stalled PR #14058 |
It is a solution if you want underruns. It was explained in #11955 (comment) and also in #15014 (comment)
|
7 participants
These properties were mostly only useful before the removal of --softvol=no. At present, mpv has its own volume mixer and never touches the audio server volume at all. There's no reason for mpv to provide these properties, if users wish to change the audio server volume, it's trivial to do so in a Lua/Javascript script.
Moreover, ao-volume presents the audio server volume as-is, meaning without any conversion or normalization. As such, the meaning of the value changes depending on the audio server in use or the configuration of the audio server. There's no correct way for mpv to do this normalization. This kind of functionality is better suited for a Lua/Javascript script where the user can normalize the values to their preferred scale, and not bloat mpv with pointless properties that are confusing and not useful.