ao/pulse: set similar properties as the pipewire backend

[pobrn]

Not setting media.role especially negatively affects wireplumber's restore-stream feature as it will save different stream settings for ao=pulse and ao=pipewire, so they will be restored differently.

For example:

1. mpv --ao=pipewire ...
2. mute the stream in pavucontrol
3. mpv --ao=pulse ...
4. note that the stream is not muted

To alleviate that issue, set media.role the same way it is set in the pipewire audio backend. (As well as some others.)

See https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3848

[github-actions[bot]]

Download the artifacts for this pull request:

Windows

• mpv-i686-w64-mingw32
• mpv-x86_64-w64-mingw32

macOS

• mpv-macos-14-arm
• mpv-macos-12-intel
• mpv-macos-13-intel

[Traneptora]

In that case this LGTM.

[jeeb]

Looked at the logic and going to test a more centralized way of cleaning up the proplist. If it looks good, I'll note it here and otherwise pull the commit in with possibly a small change (keeping pa_threaded_mainloop_unlock as the last thing in the success case - technically it wouldn't matter since the context has its own copy, but just to keep the general idea of unlocking being last.)

[pobrn]

I am not sure if this is what you have in mind, but I simplified the cleanup of props.

[jeeb]

Will finish groceries and test :) .

[jeeb]

Apparently mpv used to set the video role and hit an issue, #1173 (fixed by b7325b2f64eb66da255b9cc28b2b70b96578883d ) . Will have to figure out if this is still valid.

[pobrn]

Ahh right, that is unfortunate... as far as I can see module-role-cork is still likely in the default configuration on most distributions.

[jeeb]

I think the initial mute/lowered volume was not the problem, just that it would still go that way in case of things switching...

more specifically, I think haasn's comment @ https://github.com/mpv-player/mpv/issues/1173#issuecomment-208541364 goes through it. But I'm still trying to 100% grasp it :) .

[pobrn]

I think the initial mute/lowered volume was not the problem, just that it would still go that way in case of things switching...

I am afraid that is still happening. I just tested and I saw the following:

1. the stream is muted if another playback stream appears;
2. the stream is also muted when mpv finishes playing and switches to the next track (interestingly that does not happen if I use arrow buttons on the UI to switch tracks)

[sfan5]

So, is this good to go or are there still issues with this change?

[pobrn]

The only slightly problematic part is

pa_proplist_sets(props, PA_PROP_MEDIA_ROLE, ao->init_flags & AO_INIT_MEDIA_ROLE_MUSIC ?  "music" : "video");

in the diff. Unfortunately that is what would "fix" the issue reported on the pipewire bug tracker. It would essentially "reopen" #1173, although one can easily fix that by not loading module-role-cork or excluding video from roles that module-role-cork corks.

[kasper93]

Do we maybe want to merge this without PA_PROP_MEDIA_ROLE, if there are problems? Just app names.

[pobrn]

Do we maybe want to merge this without PA_PROP_MEDIA_ROLE, if there are problems? Just app names.

That does not address the reason I propose this change, which is the inconsistent stream restore behaviour depending on which audio backend mpv uses.

---

As mentioned in the referenced issue, VLC also sets media.role; and this behaviour can easily be avoided by unloding module-role-{cork,duck} (and possibly module-augment-properties) in ~/.config/pulse/default.pa.

---

I think it would be nice to keep the property list as consistent as possible between the two backends, but in the end it is a small thing. So how can we move forward from here?