module-rescue-streams uses different logic for selecting the target sink than what the core uses for selecting the new default sink when the old default sink disappears. This causes unexpected behaviour in the following scenario: - there are three sinks: A, B and C - A is the default sink - there's a stream playing to A - A disappears, module-rescue-stream moves the stream to B, and C becomes the new default sink (this is already a bit unexpected, but it gets worse) - A appears again - module-switch-on-connect makes A the default sink. module-switch-on-connect should also move the stream back to A, but it doesn't, because the stream is now playing to B, which is a non-default sink, so module-switch-on-connect assumes that the user explicitly moved the stream to B, which the user did not do. This problem could be avoided if module-rescue-streams used the same logic as what is used for choosing the new default sink when the old default sink disappears. To ensure that the logic is exactly the same, the logic should be implemented in a shared function that is used in both cases.
Example from real life: I have a laptop with three sinks: - Default speakers - Remote server - Bluetooth headset Normally PA uses default speakers as expected. When I use BT headset, I switch output to it. After using headset I disconnect it, and Pulseaudio sets default sink to remote server. This is clearly wrong. Expected behavior would be to revert to default (or previously used?) sink.
internal speaker cannot disappear, why pulseaudio assign highest priority to speaker ? this mean you have to make speaker disappear when headphone is plugged headphone 's priortiy should be higher than internal speaker
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/190.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.