SDL3 + PipeWire reports app name twice

[Tiagoquix]

Originally discussed as a side issue in ValveSoftware/Source-1-Games#8018.

SDL3 seems to be reporting both an application's name and an audio stream for the PipeWire backend even if both share the same name.

---

SDL AUDIO = pulseaudio ; STEAM COMPAT = unset (SDL3)

SDL AUDIO = pulseaudio ; STEAM COMPAT = classic (pure SDL2)

SDL AUDIO = pipewire ; STEAM COMPAT = unset (SDL3)

SDL AUDIO = pipewire ; STEAM COMPAT = classic (pure SDL2)

(same as SDL AUDIO = pulseaudio ; STEAM COMPAT = classic (pure SDL2))

---

The tests above were done for the Steam Linux Runtime (which includes SDL) to demonstrate the differences:

• Pure SDL2 ("classic" mode, non-sdl2-compat), either with PipeWire or PulseAudio, always reports just the binary file name (tf_linux64, for Team Fortress 2).
• SDL3, via sdl2-compat, has different behavior depending on the audio backend:
  • For PulseAudio, via pipewire-pulse, it correctly assigns a game (controller) icon (instead of being a generic sound icon), and reports just one name (the binary file name).
  • However, for PipeWire, it seems to be reporting both the app name and the stream name (according to McVittie's comment in [Team Fortress 2] [Linux] Alt+tab freeze and wrong name in sound mixer after recent update (fix included) ValveSoftware/Source-1-Games#8018 (comment)); that would be PW_KEY_APP_NAME and PW_KEY_MEDIA_NAME, according to McVittie's logic.

From my point of view as an end-user, it does not make sense for it to display tf_linux64 with SDL3 + PipeWire. I believe this to be a SDL regression rather than a problem with KDE Plasma's sound applet, since previous iterations (PulseAudio and/or SDL2) would not report it twice.

I think it would be desirable to make it so SDL3 + PipeWire only reports one instance of tf_linux64, especially because it seems to be just a single audio stream, so there is no advantage, as I see it, from reporting both the app name and the stream name, even though that may be correct in PipeWire terms.

CC @smcv

Thank you for your attention.

[smcv]

This is related to #15692, in which the app name signalled to Pipewire fell back to SDL Application rather than the executable's basename.

[slouken]

For more context from @smcv:
ValveSoftware/Source-1-Games#8018 (comment)

It looks as though SDL3 with its default Pipewire backend is telling Pipewire two facts:

• I am an app named tf_linux64 (PW_KEY_APP_NAME in Pipewire jargon, for example this is where a music player would put its application name)
• Here is my audio stream, its name is tf_linux64 (PW_KEY_MEDIA_NAME in Pipewire jargon, for example this is where a music player might say the artist and track name that it is currently playing)

Meanwhile SDL3 with the PulseAudio backend, or "classic" SDL2 with either the PulseAudio or Pipewire backend, is either telling the audio server only one of those two facts, or perhaps neither of them. (Or in the case of the PulseAudio backend, maybe it's trying to send both, but one of them is getting lost as it passes through pipewire-pulse.)

If you think SDL is incorrect to set the default audio stream name to its app name, I'd recommend reporting that in https://github.com/libsdl-org/SDL/issues. I could open an issue over there for you, but you would probably be more convincing than I would, because I'm personally not at all sure that SDL is doing anything wrong. If the SDL team agree with you and change SDL's behaviour, then the Steam Runtime will pick up that change when a new SDL is released.

The result of setting both an app name and an audio stream name is that your volume applet has chosen to display it as tf_linux64 • tf_linux64. You can think of this as equivalent to a music player like Amarok being shown as something like Amarok • Iron Maiden - The Trooper if it provides both an app name and an audio stream name.

I can see that the end result - the audio stream being described as tf_linux64 • tf_linux64 by your volume applet - is not what you want, but it's your volume applet's UI choice that it is presenting the available information in that way, and it could easily eliminate duplicates before displaying them, if it wanted to. That would be another way to avoid that end result.

[smcv]

It might be interesting to compare with the result of running TF2 with SDL_APP_NAME="Team Fortress 2" and SDL_AUDIO_DEVICE_STREAM_NAME="TF2's audio stream" in the environment, to mimic what would happen if TF2 was providing this information. I would expect this to show up in KDE's UI as something like Team Fortress 2 • TF2's audio stream.

[Tiagoquix]

(Tested with SLR Sniper version 3.0.20260602.240810, which should be the latest stable version of SDL as of today.)

---

• SDL_APP_NAME="Team Fortress 2"
• SDL_AUDIO_DEVICE_STREAM_NAME="TF2's audio stream"
• SDL_AUDIO_DRIVER=pulseaudio
• STEAM_COMPAT_RUNTIME_SDL2 unset

---

• SDL_APP_NAME="Team Fortress 2"
• SDL_AUDIO_DEVICE_STREAM_NAME="TF2's audio stream"
• SDL_AUDIO_DRIVER=pipewire
• STEAM_COMPAT_RUNTIME_SDL2 unset

(same result)

---

• SDL_APP_NAME unset
• SDL_AUDIO_DEVICE_STREAM_NAME="TF2's audio stream"
• SDL_AUDIO_DRIVER unset
• STEAM_COMPAT_RUNTIME_SDL2 unset

[smcv]

Well, that's strange. I don't understand why setting SDL_AUDIO_DEVICE_STREAM_NAME would eliminate the second item shown in the UI (which I thought was coming from SDL's default/fallback stream name), but not show the stream name that you've forced via the hint either...

[smcv]

Tested with SLR Sniper version 3.0.20260602.240810, which should be the latest stable version of SDL as of today.

Yes, this version of sniper has SDL 3.4.10, and uses it to implement the SDL2 API via sdl2-compat by default.

[icculus]

I put a fix in for this, to not set a stream name if the PipeWire node name (the app's name, in this case) is the same.

Note that Ubuntu (22.04 at least) doesn't show both names, so this doesn't reproduce for me, but it should resolve the issue for other people.

Also worth noting that the PulseAudio backend sets the equivalent data to the app's name and "Audio Stream" if it doesn't have a better metadata to go with, which is different than what PipeWire does. But I'm inclined to leave this alone until someone complains.

[Tiagoquix]

Thanks for the fix @icculus.

Note that Ubuntu (22.04 at least) doesn't show both names, so this doesn't reproduce for me

Possibly because of either some out-of-date library or of it being GNOME? My test was on Arch Linux, fully up-to-date, and KDE.

Also worth noting that the PulseAudio backend sets the equivalent data to the app's name and "Audio Stream" if it doesn't have a better metadata to go with, which is different than what PipeWire does. But I'm inclined to leave this alone until someone complains.

Doesn't that simply mean that the end result (the name displayed) would be the same in both PulseAudio and PipeWire when the app doesn't set a stream name, even without your fix?

[icculus]

Possibly because of either some out-of-date library or of it being GNOME? My test was on Arch Linux, fully up-to-date, and KDE.

It's probably either my Gnome being 2+ years out of date, or something Ubuntu disabled, but I don't know.

Doesn't that simply mean that the end result (the name displayed) would be the same in both PulseAudio and PipeWire when the app doesn't set a stream name, even without your fix?

I assume it would show "Game Name - Audio Stream" instead of "Game Name" on Pulse, but again, I haven't tested this.