Bug 432487

(In reply to Nate Graham from comment #0)
> This not only changes the default but also moves all current
> streams.

I think this is wrong behavior. Clicking the radio button should only move streams that haven't been manually assigned to another device. The "play/record all audio streams via this device" should be used when you want to force all streams to that device, even though they may have been manually assigned to another device.

Use case:
1.) I launch Spotify and want to play classical music on my Bluetooth speaker as ambient noise for me and my roommate. I assign the Spotify stream to my Bluetooth speaker.

2.) I get pulled into an audio conference. I click the radio button next to my wireless headset device to set that as the default. All streams BUT the Spotify stream gets assigned to my headset. This is great because I get to have my audio conference in private and my roommate still gets to enjoy the music.

3.) Roommate leaves and now I want all streams on my headset. I click the "Play/record all audio stream via this device" and all streams INCLUDING the Spotify stream gets switched over to my headset.

This feature isn't redundant. I think the REAL problem here is that clicking the default device radio button switches all streams, even though some of them may have been manually assigned to something else.

You may be right. However for the common case, the user probably does want to move all streams when they change the playback device. It's only in certain unusual circumstances where they don't. So we want to make sure that we don't impair the common and simple use case to better support advanced and complicated ones.

But the common and simple use case doesn't involve users manually setting streams to specific devices. They'll usually only use the radio buttons to switch the default device, in which case it will already work as if it was switching all streams because none of the streams have been "fixed" to a device.

When a user consciously decides to set a specific application to a specific device, the advanced use case already comes into play and I'd argue that users would in fact be confused when an application that they've manually sent to another device suddenly gets switched over when they change the global default device.

Here's what I propose as a compromise:
1.) Remove the "Play all audio through this device" button as you suggested.
2.) Implement a "Lock to device" button in the device menu for each individual audio stream so that we don't impair the advanced use case and more clearly signal to the user that this stream will NOT move along with the default device.
3.) Add a single "Reset all audio streams to default device" button under the Applications tab so that users can quickly restore everything back to normal.

The Plasma PA widget is so much more flexible than Gnome's audio settings. It would be a shame to lose that and devolve down to their limited use case. KDE users want the customizability.

That seems like a great compromise to me!

*** Bug 491029 has been marked as a duplicate of this bug. ***

Due to some clients being bad and setting the default device at their startup as their explicitly chosen target, which essentially breaks default device switching later on, both PA and PW now ignore target.object value when it matches the current default. It's annoying but there's no other way when client software is pulling such shenanigans.

For the above reason, I don't think it's possible to implement lock to device functionality for cases where the desired sink or source matches the current default within the current PulseAudio API. The best solution would likely be to work with either PipeWire or WirePlumber on a new API call that would be restricted to privileged clients such as plasma-pa and allow an explicit target.object override.

Alternatively it might be possible to keep the old behavior for when a client sets its own target.object but permit a privileged client to set the value "for realz". Doing so would permit this without modifying the existing PA API by only changing the audio server internals. 

Either way someone will need to figure out the priority of such an override i.e. is plasma-pa higher precedence than the client making its own choice and I don't know enough to say one way or another, since both are supposed to be user controlled and having them mismatch would be terrible UX.