ao_pipewire: avoid setting any media.role by default

[llyyr]

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:
b7325b2

Fixes #16459 #16370 and similar
Fixes #16978

[sfan5]

please link https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/489 in the description too

[sfan5]

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
			}
		}
	}
]

[llyyr]

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

[WhitePeter]

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]

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

Only the ones who don't like this.

[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. This is an anti-feature and there's a reason why mpv stopped setting the media role for PA backend in 2015.

[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.

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.

[llyyr]

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.

[WhitePeter]

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]

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

[llyyr]

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 #15835 (comment)

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.

[WhitePeter]

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?

[DanOscarsson]

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.

[WhitePeter]

@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.

[franzitrone]

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: franzitrone@776966e

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

[llyyr]

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

[kasper93]

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.

[sfan5]

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: 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)

[kasper93]

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.

[sfan5]

LGTM otherweise