mpv audio and spotify share the same volume level

[adxria]

mpv Information

mpv v0.40.0-dirty Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects
 built on Oct  4 2025 16:40:45
libplacebo version: v7.351.0
FFmpeg version: n8.0
FFmpeg library versions:
   libavcodec      62.11.100
   libavdevice     62.1.100
   libavfilter     11.4.100
   libavformat     62.3.100
   libavutil       60.8.100
   libswresample   6.1.100
   libswscale      9.1.100

Other Information

- Linux version: Arch Linux
- Kernel Version: Linux loq15iax9 6.17.5-arch1-1.1 #1 SMP PREEMPT_DYNAMIC Sat, 25 Oct 2025 04:05:25 +0000 x86_64 GNU/Linux
- GPU Model:

00:02.0 VGA compatible controller [0300]: Intel Corporation Alder Lake-S [UHD Graphics] [8086:468b] (rev 0c)
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation AD107M [GeForce RTX 4050 Max-Q / Mobile] [10de:28e1] (rev a1)

- Mesa/GPU Driver Version: `OpenGL version string: 4.6.0 NVIDIA 580.95.05`
- Window Manager and Version: Hyprland 0.51.1
- Source of mpv: form Arch's repo `sudo pacman -S mpv`
- Latest known working version: N/A
- Issue started after the following happened: N/A

Reproduction Steps

• Have a spotify package from arch official repo: spotify-launcher 0.6.3-2.1
• Change the volume level via spotify's volume knob or pavucontrol (let's say set it to 40%)
• Open an audio file (not a video) with mpv

Expected Behavior

mpv should have an independent volume from spotify (spotify at 40%, mpv at 100%).

Actual Behavior

mpv's volume is lowered to 40%
If you change it back to 100% through pavucontrol, it stays that way until you adjust spotify’s volume again and reopen the mpv audio file.

Log File

output.txt

Sample Files

I have a video demonstration

mpv_spotify_issue.mp4

I carefully read all instruction and confirm that I did the following:

• I tested with the latest mpv version to validate that the issue is not already fixed.
• I provided all required information including system and mpv version.
• I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
• I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• I attached the full, untruncated log file.
• I attached the backtrace in the case of a crash.

[adxria]

Additional info:
I have this issue for several months already. I've discovered it while using software called Anki (it opens mpv for audio files and then closes it, when the end of the file is reached). That means, whenever i use spotify with anki, my volume is always lower than expected 100%.

I'm a newbie in linux so i'm not sure how everything works, but what i've found so far:
pactl list sink-inputs output:

Sink Input #224
	Driver: PipeWire
	Owner Module: n/a
	Client: 223
	Sink: 107
	Sample Specification: float32le 2ch 44100Hz
	Channel Map: front-left,front-right
	Format: pcm, format.sample_format = "\"float32le\""  format.rate = "44100"  format.channels = "2"  format.channel_map = "\"front-left,front-right\""
	Corked: no
	Mute: no
	Volume: front-left: 26195 /  40% / -23.90 dB,   front-right: 26195 /  40% / -23.90 dB
	        balance 0.00
	Buffer Latency: 0 usec
	Sink Latency: 0 usec
	Resample method: PipeWire
	Properties:
		client.api = "pipewire-pulse"
		pulse.server.type = "unix"
		application.name = "spotify"
		application.process.id = "25686"
		application.process.user = "adoria"
		application.process.host = "loq15iax9"
		application.process.binary = "spotify"
		application.language = "en_US.UTF-8"
		window.x11.display = ":1"
		application.process.machine_id = "624b2e0bafff4293a2ccbb9c324b3658"
		application.process.session_id = "2"
		media.role = "music"
		media.name = "Spotify"
		pulse.corked = "false"
		node.rate = "1/44100"
		node.latency = "8192/44100"
		stream.is-live = "true"
		node.name = "spotify"
		node.want-driver = "true"
		node.autoconnect = "true"
		media.class = "Stream/Output/Audio"
		port.group = "stream.0"
		adapt.follower.spa-node = ""
		object.register = "false"
		factory.id = "7"
		clock.quantum-limit = "8192"
		node.loop.name = "data-loop.0"
		library.name = "audioconvert/libspa-audioconvert"
		client.id = "89"
		object.id = "83"
		object.serial = "224"
		pulse.attr.maxlength = "4194304"
		pulse.attr.tlength = "640064"
		pulse.attr.prebuf = "0"
		pulse.attr.minreq = "7056"
		node.driver-id = "76"
		module-stream-restore.id = "sink-input-by-media-role:music"

Sink Input #939
	Driver: PipeWire
	Owner Module: n/a
	Client: 938
	Sink: 107
	Sample Specification: float32le 2ch 48000Hz
	Channel Map: front-left,front-right
	Format: pcm, format.sample_format = "\"float32ne\""  format.rate = "48000"  format.channels = "2"  format.channel_map = "\"front-left,front-right\""
	Corked: no
	Mute: no
	Volume: front-left: 26195 /  40% / -23.90 dB,   front-right: 26195 /  40% / -23.90 dB
	        balance 0.00
	Buffer Latency: 0 usec
	Sink Latency: 0 usec
	Resample method: PipeWire
	Properties:
		media.type = "Audio"
		media.category = "Playback"
		media.role = "music"
		node.name = "mpv"
		device.description = "mpv"
		application.name = "mpv"
		application.id = "mpv"
		application.icon_name = "mpv"
		node.always-process = "true"
		node.rate = "1/48000"
		media.name = "Letters - Sillent Hill 2 OST [acQrKPVA32I].mp3 - mpv"
		stream.is-live = "true"
		node.want-driver = "true"
		node.autoconnect = "true"
		media.class = "Stream/Output/Audio"
		port.group = "stream.0"
		adapt.follower.spa-node = ""
		object.register = "false"
		factory.id = "9"
		clock.quantum-limit = "8192"
		node.loop.name = "data-loop.0"
		library.name = "audioconvert/libspa-audioconvert"
		client.id = "162"
		object.id = "158"
		object.serial = "939"
		node.driver-id = "76"
		module-stream-restore.id = "sink-input-by-media-role:music"

So both mpv and anki utilize the same media role: media.role = "music"
and both have module-stream-restore.id = "sink-input-by-media-role:music"
I think that's the culprit. My attempt to find any information about media roles was unsuccessful. As far as I understand, I can't change the media role using a wireplumber config

I've seen a very similar issue here, but it was closed two years ago as not planned
#13135

My packages, if that helps:

anki-bin 25.09.2-1 (aur)
spotify-launcher 0.6.3-2.1
lib32-libpipewire 1:1.4.9-1
lib32-pipewire 1:1.4.9-1
libpipewire 1:1.4.9-1
pipewire 1:1.4.9-1
pipewire-alsa 1:1.4.9-1
pipewire-audio 1:1.4.9-1
pipewire-jack 1:1.4.9-1
pipewire-pulse 1:1.4.9-1
alsa-card-profiles 1:1.4.9-1
alsa-lib 1.2.14-1.1
alsa-plugins 1:1.2.12-5.1
alsa-topology-conf 1.2.5.1-4
alsa-ucm-conf 1.2.14-2
alsa-utils 1.2.14-1.1
lib32-alsa-lib 1.2.14-1.1
lib32-alsa-plugins 1.2.12-1.1
libwireplumber 0.5.12-1.1
wireplumber 0.5.12-1.1
mpv 1:0.40.0-7.1

I'm very sorry if my english is bad or if i screwed the template or if the issue is simple and i'm just dumb

[WhitePeter]

This is not a bug. The restoration of streams with all their properties, including volume, is working as intended, IIUC. When playing pure audio mpv sets media role to "music"` but when playing videos it sets it to "video" which makes for two distinct routes for pipewire to take when deciding which volume to restore. I've just checked, pipewire restores the correct volume for the "video" role, which is independent of "audio". So everything in the chain is doing what it's supposed to do.

If you want to change something about it, my best guess is the configuration of wireplumber, the session manager of pipewire. I believe there is a way to restore by stream/application name, for instance. At least there used to be with pusleaudio, pipewire's predecessor. Or just get used to it. It does not sound totally unreasonable to have different volume levels for video and pure music. I, for one, do like it. Features like that make pipewire worthwhile.

Or, if you don't want this at all, you can try different audio outputs, i.e. --ao=alsa. But that may require to disable pipewire altogether, because it needs exclusive access to the hardware.

[adxria]

Thank you very much for your response!

This is not a bug

That's unfortunate for me. Having ability to change the name of media role would be helpful. I seen it was discussed a year ago in the pull request, but it seems that media roles are still hard coded..? At least i couldn't find any information about that in manual
#11253

configuration of wireplumber

Last time i touched it i had zero success. Probably skill issue, but if anyone has managed to disable media role restoration, i would be grateful for any help.

---

Features like that make pipewire worthwhile.

Just my subjective opinion. I don't get the point of this feature of volume restoration by media role. Having the same volume level for a media role doesn't ensure that all sources of sound will be identical in terms of volume. Two different audio sources can differ dramatically in LUFS. Let's say I listen to metal after calm classical music. The difference in LUFS will be significant, and what's the point of this system if i still have to tinker the volume? Besides that, in the case of audio, I mainly use mpv for sounds (some sfx files, or anki's audio as discussed before), not for music. Those kind of files are not really music, right?
Just expressing my indignation, ignore it.

[adxria]

Anyway thanks for helping me. I guess i'm closing this issue, since it is not considered as a bug. I try to tinker wireplumber. Or build mpv with different audio media role lol. Looking forward to have ability to change the media role if this ever gets released

[WhitePeter]

I've found a semi-permanent workaround, perhaps. You can try forcing pulseaudio audio output with --ao=pulse. That should trigger the legacy pulseaudio protocol. Doing so makes Pipewire restore by name. You can also change the name, e.g. --audio-client-name=my-mpv. A quick test with both options set seems to do what you want, because the pipewire-pulse api does not seem to support media roles. I think overriding the name is unnecessary but may provide additional room for dealing with this.

[adxria]

OMFG, THANK YOU! THANK YOU! YOU'RE THE LEGEND
I genuinely appreciate your help. You literally single-handedly solved an issue that gave me headaches for several months in one day, just pulled that shit out from the back pocket and gave it to me, and it was good!
Thank you, WhitePeter!

[llyyr]

That is not the ideal fix, the correct fix is the PR linked.

[WhitePeter]

BTW, to change how pipewire restores stream properties, one just needs to change the order in findSuitableKey. Just mkdir -p ~/.config/wireplumber/scripts && cp /usr/share/wireplumber/scripts/restore-stream.lua ~/.config/wireplumber/scripts and change it there:

-- DON'T just copy this section to an empty file, use above commands to make a user config copy.
function findSuitableKey(properties)  -- this should be on line 107 or thereabouts
  local keys = {
    "application.id",
    "application.name",
    "media.role",
    "media.name",
    "node.name",
  }

The above moves media.role from the top of the list to after application.* thus they are being tried first and will be found, in case of mpv at least. See, easy! Don't go throwing out the babe with the bathwater. ;)

[llyyr]

I never said it wasn't possible to make wireplumber to do this, it's immensely scriptable and it can probably do just about anything.

The point is that it's not a simple one config option change, and also that every user needs to set it manually.

Don't go throwing out the babe with the bathwater

You can also set a default media role for mpv in wireplumber, since you like current behavior so much.

[WhitePeter]

In fact, I don't have to do anything right now. And I won't be able to set differing roles depending on media content, because only mpv can know and I have no way of querying that, do I? So technically this is regression.

[llyyr]

You can set a different --audio-client-name for mpv based on whether it's playing audio or video with audio, then use it to assign a different media.role in wireplumber.