mpv icon indicating copy to clipboard operation
mpv copied to clipboard

ao_pipewire: avoid setting any media.role by default

Open llyyr opened this issue 1 month ago • 18 comments

By default, WirePlumber restores the volume of each application to whatever the last application with the same media role used. This is completely insane behavior, and I couldn’t find any way for a user to opt out of it on my end. The state-stream.lua script responsible for this mess only uses media.role if the property is present, so the only reliable workaround is simply not to set one at all.

This WirePlumber behavior is inherited from PulseAudio, which also exhibits the same behavior to this day.

This commit also mirrors the same change made to ao_pulse in 2015: https://github.com/mpv-player/mpv/commit/b7325b2f64eb66da255b9cc28b2b70b96578883d

Fixes https://github.com/mpv-player/mpv/issues/16459 https://github.com/mpv-player/mpv/issues/16370 and similar Fixes https://github.com/mpv-player/mpv/issues/16978

llyyr avatar Nov 14 '25 03:11 llyyr

I'm not sure if it's this exact issue, but I found the volume preserving behavior of pipewire to be obstructive/wrong when I switched to it years ago. So I set the following config to disable it (~/.config/wireplumber/wireplumber.conf.d/55-stream.conf):

stream.rules = [
	{
		matches = [
			{ application.id = "~mpv" }
		]
		actions = {
			update-props = {
				state.restore-props = false
			}
		}
	}
]

sfan5 avatar Nov 14 '25 09:11 sfan5

That should avoid the issue but it would require every user to independently set that config.

llyyr avatar Nov 14 '25 10:11 llyyr

Why not simply set "Movie" as the media role unconditionally?

Also, this is a config issue with wireplumber. It should be possible to tell it to not restore based on media.role. I, for one, like to listen to music at low volume as kind of background noise. But when I watch a video I want considerably more volume. So these roles fit the bill.

Could this not be solved by an option to set the media role? That combined with conditional autoprofiles could make both camps happy, I think.

WhitePeter avatar Nov 14 '25 10:11 WhitePeter

That should avoid the issue but it would require every user to independently set that config.

Only the ones who don't like this.

WhitePeter avatar Nov 14 '25 10:11 WhitePeter

Why not simply set "Movie" as the media role unconditionally?

Because this doesn't avoid the issue that mpv's volume will be tied to any other app that uses the "Movie" media role. This is an anti-feature and there's a reason why mpv stopped setting the media role for PA backend in 2015.

llyyr avatar Nov 14 '25 10:11 llyyr

Why not simply set "Movie" as the media role unconditionally?

Because this doesn't avoid the issue that mpv's volume will be tied to any other app that uses the "Movie" media role.

Fair enough.

This is an anti-feature and there's a reason why mpv stopped setting the media role for PA backend in 2015.

It is for you and some others. How many issues are there complaining about this? That should be the watermark, I think.

WhitePeter avatar Nov 14 '25 10:11 WhitePeter

It is for you and some others. How many issues are there complaining about this? That should be the watermark, I think.

Across the linked issues, there's 12 unique users who've complained about this, and I didn't look to see if this issue was reported in some other ticket as well. There's also usually one person asking about this in the IRC channel on a monthly basis. It is much more likely that many users don't even report this and just go along their day using ao_pulse because it doesn't set the media.role and thus doesn't exhibit this obstructive behavior.

llyyr avatar Nov 14 '25 10:11 llyyr

Doesn't mean it has to go entirely. Also, there are other reasons whey pipewire ao is not popular with mpv, the sucky volume control, remember? You seem hellbent on crippling it even further.

WhitePeter avatar Nov 14 '25 11:11 WhitePeter

All I'm trying to say, if you find pulseaudio so annoying why do you make the transition to pipewire so unattractive?

WhitePeter avatar Nov 14 '25 11:11 WhitePeter

Please stop responding with off topic comments, they have nothing to do with this PR but I'll respond anyway.

Doesn't mean it has to go entirely. Also, there are other reasons whey pipewire ao is not popular with mpv, the sucky volume control, remember? You seem hellbent on crippling it even further.

I summarized my thoughts concisely in this comment here https://github.com/mpv-player/mpv/pull/15835#issuecomment-2647821363

All I'm trying to say, if you find pulseaudio so annoying why do you make the transition to pipewire so unattractive?

I'm fixing bugs that at least a dozen people complained about if not more, and even upstream isn't sure if said feature should exist or not.

llyyr avatar Nov 14 '25 11:11 llyyr

Please stop responding with off topic comments, they have nothing to do with this PR but I'll respond anyway.

The hint about the ao-volume control was meant to tell you that there may be other reasons why people don't come complaining about ao-pipewire, like almost nobody using it for reasons like e.g. sucky ao-volume handling. So it was topic adjacent.

Doesn't mean it has to go entirely. Also, there are other reasons whey pipewire ao is not popular with mpv, the sucky volume control, remember? You seem hellbent on crippling it even further.

I summarized my thoughts concisely in this comment here #15835 (comment)

And you only demonstrated that you missed the real issue. My mistake was to mention other semi-related issues which I came by when researching pre-PR... But, I'll say no more on that particular matter.

All I'm trying to say, if you find pulseaudio so annoying why do you make the transition to pipewire so unattractive?

I'm fixing bugs that at least a dozen people complained about if not more, and even upstream isn't sure if said feature should exist or not.

No, if anything, you are trying to fix pipewire's bugs, or work around them, rather. And a bug this ain't; as stated, not only by me, this is intended behavior and there is no error anywhere in the chain. It boils down to preference. And how to change that in a totally non-destructive way has been shown as well.

I implore you to reconsider. Babies, bathwater and all that. Sometimes it is just a PEBCAK situation and users just need to RTFM. Counter offer: How about I write something up in the documentation section for ao-pw and wherever else you please? First, explain the media.role thing and how to change pw prefs. Basically, the man page asks users all the time to change some file; it just happens to be its own config. So why not just tell people "not our bug" and redirect them to the correct source?

WhitePeter avatar Nov 14 '25 13:11 WhitePeter

Maybe users can do for pipewire like I do for pulseaudio. When playing music I set a audio client name that is different from when playing a video. This results i one volume retained for music and an other volume retained for video, when using mpv.

DanOscarsson avatar Nov 14 '25 14:11 DanOscarsson

@DanOscarsson thanks for chiming in. So, you're basically working around mpv dropping that functionality. Case in point. ;) That's also not quite the same as setting media.role, because any client that also serves that same role, i.e. spotify in the linked issue, will share the restoration properties. You would need to bend pipewire's will some to make it assign the media.role base on the client name. It doesn't matter when one uses mpv exclusively, and why wouldn't one? But others may feel differently, have different preferences.

I think one just needs to compare the amount of work involved in either changing wireplumber stream restoration precedence now, which boils down to (re)moving one single line, or in the future creating an autoprofile to hack mpv's advertised client name based on presence of video track (how do I iterate over the tracks table in one Lua expression?) and hack some wireplumber script to then assign the correct media role.

WhitePeter avatar Nov 14 '25 14:11 WhitePeter

I'd like to chime in as well at this point.

I personally use exactly the media.role property to link applications to specific outputs without having to specify each application explicitly. This way, I can change the respective sink's name easily, without having to change several configs. But it relies on applications to set meaningful media.role properties.

Hence, I find a command line option to set the media role explicitly to be the most flexible and least intrusive change. I have been using it this way for a while now: https://github.com/franzitrone/mpv/commit/776966ee9e9bb2a687b7a58d0cda4d443dec127a

Although the commit above is probably rather hacky and only served as a personal patch/hack.

franzitrone avatar Nov 14 '25 16:11 franzitrone

I've made it an option that's disabled by default, and also made it set it for pulse depending on the option

llyyr avatar Nov 15 '25 00:11 llyyr

This is disabled by default per media role volumes have often caused unexpected and confusing behavior.

Isn't this not our problem? And should be directed as a bugs to upstream projects? I feel like we are trying to workaround issue that we shouldn't have.

kasper93 avatar Nov 18 '25 15:11 kasper93

I feel like we are trying to workaround issue that we shouldn't have.

it's far too late for that, because "we" (more specifically wm4 decided to) already worked around this in 2015: b7325b2f64eb66da255b9cc28b2b70b96578883d

also here's the upstream issue for pipewire: https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/489 does it look like anything is going to happen there? (hint: no)

sfan5 avatar Nov 18 '25 15:11 sfan5

I feel like we are trying to workaround issue that we shouldn't have.

it's far too late for that, because "we" already worked around this in 2015: b7325b2

also here's the upstream issue for pipewire: https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/489 does it look like anything is going to happen there? (hint: no)

Ok. In this case "we" can have this change.

kasper93 avatar Nov 18 '25 15:11 kasper93