ao_pipewire: revert cubic volume curves, update docs

[winex]

fix #11065

[na-na-hi]

In addition to #15835 (comment), it is worth pointing out that the documentation wording below:

What this option does, or how the value is interpreted depends on the API.

is simply describing that the behavior differs depending on the API. There is no guarantee that it provides any kind of "1:1" mapping to the underlying raw API values. If wpctl as a frontend can perform cubic conversion to the underlying raw values, so can mpv.

[llyyr]

wpctl is a frontend, ao-volume is a low level property that really shouldn't even exist considering mpv has its own volume mixer. If you want ao-volume to become a front end, you need to implement proper conversion for every AO mpv supports, not just Pipewire. Some AOs can be configured to be in cubic or linear, like ALSA and there's no way to figure out which one it is. Implementing the API required to retrieve what volume scale ALSA is using is an exercise for the PR contributor.

[na-na-hi]

ao-volume is a low level property

This has never been true. Before --softvol was removed, --volume controlled AO volume. --volume is directly controlled by mpv frontend and it is definitely not a low level property.

If you want ao-volume to become a front end, you need to implement proper conversion for every AO mpv supports, not just Pipewire.

This fixes ao-volume for pipewire. If you want to fix other AOs, PR welcome.

that really shouldn't even exist considering mpv has its own volume mixer

If you want to remove this, PR welcome. This is off-topic in this PR.

Some AOs can be configured to be in cubic or linear, like ALSA and there's no way to figure out which one it is.

If there is no correct way to do it as you are indicating here, then you cannot say that "1:1" mapping is the correct method.

[llyyr]

then you cannot say that "1:1" mapping is the correct method.

Where have I said that? I'm saying that since there's no correct way to do this, we should let the user figure out what the values mean and convert them to their preferred scale in a script or such. The user is going to know more about their audio server and its configuration than mpv, as it stands.

This has never been true.

Does your definition of "never" not encompass the present? Because it's true in the present right now, and will be in the future as well unless you bring softvol=no back.

This fixes ao-volume for pipewire

It does not "fix" ao-volume for Pipewire. It makes ao-volume do a special thing only for Pipewire, but not for others.

[na-na-hi]

I'm saying that since there's no correct way to do this, we should let the user figure out what the values mean and convert them to their preferred scale in a script or such. The user is going to know more about their audio server and its configuration than mpv, as it stands.

This assumes that the conversion can be performed. How does the user perform the conversion if there is no "1:1" mapping guarantee?

Does your definition of "never" not encompass the present? Because it's true in the present right now, and will be in the future as well unless you bring softvol=no back.

Where in the current documentation says that it is a low level property?

It does not "fix" ao-volume for Pipewire. It makes ao-volume do a special thing only for Pipewire, but not for others.

Where in the current documentation says that "1:1" mapping is specified behavior, and the behavior in this PR is not allowed?

[llyyr]

This assumes that the conversion can be performed. How does the user perform the conversion if there is no "1:1" mapping guarantee?

The user will know if they configured their audio server to use cubic or linear mapping. mpv won't, unless it starts reading config files for entirely unrelated applications.

Where in the current documentation says that it is a low level property?
Where in the current documentation says that "1:1" mapping is specified behavior, and the behavior in this PR is not allowed?

It is entirely meaningless and a waste of time to attempt to have a constructive conversation with you. I'll let the maintainers decide between this and #17704

[avih]

What if mpv could be configured to choose between 1:1 and cubic? Maybe with different default per AO if we know the default behavior of some audio servers, and 1:1 otherwise?

[llyyr]

What if mpv could be configured to choose between 1:1 and cubic? Maybe with different default per AO if we know the default behavior of some audio servers, and 1:1 otherwise?

You can have a subproperty that converts the value to cubic, but this will give you garbage (L^9) if it was already cubic. I'm personally in favor of deprecating these properties instead because there's no good way for mpv to do this, and tell users to use a script for this.

[avih]

tell users to use a script for this

Users prefer to not have to use scripts to fix problems between their media player and their audio server.

If for some audio backends mpv cannot know how it should behave, but it's still one of few known options, then for users it's preferable to configure it instead of writing a script to do whatever.

[na-na-hi]

The user will know if they configured their audio server to use cubic or linear mapping. mpv won't, unless it starts reading config files for entirely unrelated applications.

How does the user know how the mpv values are mapped to audio server values? This is only documented for ALSA and PulseAudio, not for other AOs. How do they know that the mapping is linear on pipewire, which is different from wpctl?

It is entirely meaningless and a waste of time to attempt to have a constructive conversation with you. I'll let the maintainers decide between this and #17704

The comment is related to your claim:

ao-volume is a low level property

And it remains a fact that there is no documentation to support this claim. From user perspective, the mapping between ao-volume and pipewire internal value is not documented, so there is no way for the user to do the conversion. Your argument to reject this PR is built on this claim, so it is relevent and constructive in the context of this PR to discuss whether this is true or not.

[winex]

@llyyr note that ALSA doesn't have per-application/stream volume levels at all and that's why every program made their own implementations of software volume control, and even worse - very often, those aren't backed by proper math or understanding.
PA and PW fixed that, but didn't think about fixing sliders for everyone else once and forever...

idk about ALSA requests, but we can add SPA_PROP_volume_type getter to pipewire...
though, this is what i would change in pipewire:

• change SPA_PROP_volume to cubic (by usage, similar to mpv soft-volume), so most of users and apps don't ever do these things wrong
• add SPA_PROP_volume_linear for advanced usage, like DAW apps that wants -120dB scale or w/e they like like FP64
  this is probably too hard for float precision as well: volume = 0.000000000001 // or 1e-12

but pipewire have too many "volumes" already:

SPA_PROP_channelVolumes  // --pipewire-mode=channel
SPA_PROP_volume          // --pipewire-mode=global
SPA_PROP_monitorVolumes  // when you connect monitor outputs to some playback in `qjackctl`
SPA_PROP_softVolumes
...
SPA_PROP_volumeBase
SPA_PROP_volumeStep

last 2 are interesting - i didn't know of...

under PW server the ALSA-backend volume curve could be configured in pipewire.conf like:

alsa.volume-method = cubic | linear

[winex]

ooh, what a holywar here... i can just ask being on topic of pipewire AO.

---

@llyyr

It does not "fix" ao-volume for Pipewire. It makes ao-volume do a special thing only for Pipewire, but not for others.

current PR makes things match for some of AOs mpv supports -- well, at least makes pipewire match pulse AND ALSA behaviour, except for the output device for the latter!
see my test report: #17704 (comment) for more info

tell users to use a script for this

omg, please no!

...
if cubic volumes doesn't work in any other *nix AO -- ping me and i'll look at it just to keep things consistent!

---

@avih

What if mpv could be configured to choose between 1:1 and cubic? Maybe with different default per AO if we know the default behavior of some audio servers, and 1:1 otherwise?

that's constructive proposal, but anyway every usable app will end up using cubic curves (mpv's soft-volume is damn smooth!), but as coders don't like logarithms i don't expect correct behaviour at all
me myself against log-curve here: #15836 (comment)

[github-actions]

Download the artifacts for this pull request:

Windows

• mpv-v0.41.0-dev-g131de99a8-pr17703-24241627610-aarch64-pc-windows-msvc
• mpv-v0.41.0-dev-g131de99a8-pr17703-24241627610-aarch64-pc-windows-msvc-pdb
• mpv-v0.41.0-dev-g131de99a8-pr17703-24241627610-i686-w64-mingw32
• mpv-v0.41.0-dev-g131de99a8-pr17703-24241627610-x86_64-pc-windows-msvc
• mpv-v0.41.0-dev-g131de99a8-pr17703-24241627610-x86_64-pc-windows-msvc-pdb
• mpv-v0.41.0-dev-g131de99a8-pr17703-24241627610-x86_64-w64-mingw32

macOS

• mpv-v0.41.0-dev-g131de99a8-pr17703-24241627610-macos-14-arm
• mpv-v0.41.0-dev-g131de99a8-pr17703-24241627610-macos-15-arm
• mpv-v0.41.0-dev-g131de99a8-pr17703-24241627610-macos-15-intel
• mpv-v0.41.0-dev-g131de99a8-pr17703-24241627610-macos-26-arm

[winex]

ok, file extension is nonsense - it's just name suffix. i'll fix commit message asap

btw:

• lint-actions marks commits that are NOT related
• building so many artifacts NOT related to pipewire looks wasteful to me