Mpv: Regression in pulseaudio handling, 0.18.1 always starts with 100% volume.

[markg85]

Hi,

I'm using ArchLinux and tend to stay fairly updated and am using ao=pulse as sound output.
A few days ago i started noticing that when i start mpv the volume is always at 100%.

Now the regression here is that you now seem to have two mpv volume levels. There is one in "pavucontrol" (the pulseaudio volume control application), changing the volume there changes the sound output in mpv, but the "volume percentage" in mpv stays exactly where it is. The opposite is also true, if you change the volume in mpv the volume slider in pavucontrol doesn't change accordingly.

This probably also causes the bug that the volume is at 100% at startup. The correct volume is set in pavucontrol, but apparently not being received by mpv.

At first i was blaming myself since i had just been playing with pulseaudio settings (as a user), but a clean user showed the exact same issues as i just described. So i downgraded mpv to 0.18.0 to see if that would fix things, and it did. It remembers the volume just fine, resumes at the level where it was left and changing the volume in pavucontrol changes it in mpv (and the other way around).

If there is anything you want me to test to get this debugged, command outputs to give.. Just ask :)

Best regard,
Mark

[markg85]

Would you mind elaborating why this is a "wontfix"?

[ghost]

The change is noted in the changelog. I don't feel like switching it back.

[markg85]

You mean the fix for https://github.com/mpv-player/mpv/issues/3322?

If that's so, then i don't understand how this fixes anything.
The actual and expected results of that report are now the case when pulseaudio is used.

Could you elaborate a bit more and perhaps explain how i can get the behavior back that used to be there? You must admit, it's not such a weird wish to have the previous volume back when you start mpv.

Also, as it currently is done is completely counter intuitive for the user because there are in effect 2 completely independent volume controls for mpv (on in mpv itself, one in pulseaudio)

edit--
Oke, i've read the mentioned issue that removes softvol and another issue that also requested to revert it..

I see your point in getting rid of old painful code, keep doing that :)
But you must also acknowledge that the vast majority of linux distributions uses PulseAudio these days (note: i'm not a fan of pulse.. i just use it because everything these days seems to be using it). With that in mind it would be very great if the _defaults_ work with pulseaudio in mind. Right now it doesn't and users will perceive that as "a regression" like i did. Not knowing that you have to set two config options (to what, i don't know yet) which would fix it.

[markg85]

bump.. i hope you could comment on this. I'd like to know if i have to go the config route.

[ParadoxSpiral]

@markg85

Could you elaborate a bit more and perhaps explain how i can get the behavior back that used to be there? You must admit, it's not such a weird wish to have the previous volume back when you start mpv.

Use git master, and ao-volume + ao-mute for volume control.

[markg85]

Ok, fair enough.
Next question :)

I have no clue which commands i have to fill in for those fields. Do you perhaps know the ones for pulseaudio?

Also, the volume bar now apparently can go to 130%. It's fine, but i would much rather limit it to 100%. Which setting do i need to change to make 100% the max volume?

[ParadoxSpiral]

1) You set those properties like you set any other property, e.g. 9 add ao-volume -1

2) volume-max. But you won't need this if you use ao-volume + ao-mute.

[markg85]

I don't get it.

How will that property magically work with pulseaudio?

[ParadoxSpiral]

I don't know how it works, if you want to know that read the code.
But that doesn't matter, does it? It works is what's important.

EDIT:
Well, the ao-volume is just like the volume with softvol=no before the patches.

[markg85]

Really, just call me stupid if it's a silly question, but how do i set hat property?
I have a .config/mpv/mpv.cong file and it contains some properties (like ao=pulse) and that seems to work just fine.

However, if i set:
ao-volume=-1

I keep getting:
Error parsing option ao-volume (option not found)
/home/mark/.config/mpv/mpv.conf:6: setting option ao-volume='-1' failed.

I must either be missing something very obvious or it isn't obvious at all...

[kevmitch]

you don't set properties in mpv.conf, you modify them with keybindings in input.conf with lines like @ParadoxSpiral showed above, i.e.,

9 add ao-volume -1

[ghost]

And here too: https://github.com/mpv-player/mpv/wiki/FAQ#i-want-the-old-pulseaudio-volume-control-back-on-linux

[markg85]

Why did nobody nor the faq page tells anything about replacing the default volume key bindings for these new ones?

And why has this been made so extremely overly complicated?
Couldn't there just be a implicit audio detection based on ao=
Then just handle the audio out differently when it's pulse, since you seem to be desperately looking for a way to manipulate audio. I still don't see why this had to be changed at all besides cleaning up old code.

Anyhow, changing the default keys is done by adding this in input.conf:
/ add ao-volume -2
SHIFT+* add ao-volume 2

[ParadoxSpiral]

Why did nobody nor the faq page tells anything about replacing the default volume key bindings for these new ones?

The change was listed in the release notes, albeit not the implications (personally I'd like it to be more explicit).

And why has this been made so extremely overly complicated?

It's just changing keybindings, nothing too difficult. This is extensively documented.
On the other side one of the big advantages is that you now have much simpler and arguably more deterministic control over these properties which I, as a user of libmpv, greatly appreciate.

Couldn't there just be a implicit audio detection based on ao=

There could be, but imho implicit things are bad and add complexity. Changing the keybinding really isn't that complex.

I still don't see why this had to be changed at all besides cleaning up old code.

To fix the unexpected behaviour I reported, and give more control. But cleaning old code is reason enough, and entirely up to the maintainer to decide.

[markg85]

@ParadoxSpiral to be frank, the fix for your "unexpected behavior" will cause many more people to experience "unexpected behavior" just because your case was fixed.

I have no say in this, i don't code nor contribute to mpv.. But if it were up to me i'd have closed your issue as wontfix. Specially now that i know the implications it has.

[haasn]

@markyg85 mpv volume persisting across videos is quite honestly “unexpected behavior” in my books, especially since nothing else in mpv does this sort of thing.

[markg85]

@haasn then there is a difference of expectation. What you consider as unexpected is what i would consider as expected. And i'm willing to bet that the majority of linux users has the same expectation as me (audio should restore to previous levels).

I know of no other video player that does what you describe. All players that i know resume audio volume from last time. That is in windows, mac and linux. Why would it have to be different for mpv?

[haasn]

I know of no other video player that does what you describe. All players that i know resume audio volume from last time. That is in windows, mac and linux. Why would it have to be different for mpv?

Because mpv is a stateless, command-line, config-file driven, keyboard controlled minimalist player core/backend and the rest aren't? The fact that it also seems to appeal to the “GUI app” crowd is more the result of a bolted-on hack (pseudo-gui mode) than anything else.

Among command line tools, implicitly sharing state across sessions is a very weird thing to do - usually only justified for things like TOFU (e.g. ssh known hosts). (And I like my mpv as a command line tool, any way)

[markg85]

I am using it on the command line for playing radio stations.
Also for video, but radio more often.

In the technological age we live in i really would consider it a massive bug if an application cannot restore the volume as it was. Command line and gui. Right now MPV by default can't (or doesn't want to) and i consider that a massive bug!

You would have a point if we were still in the alsa age without pulseaudio or dmix for volume levels per application. Then the app should leave the volume alone and play at whatever the master volume is set. But thankfully technology moved on for the better. It's ok if you think differently, but do realize that the vast majority of the people likes to have it's volume restored to whatever it was.

It would be a different case if you start the app with an argument telling the volume to be 100% to start with. Then it's just your setting that should work however the setting is implemented. But that's not the case by default so it shouldn't happen, but somehow it is now decided that it should.