Bug 368472 - PulseAudio streams are moved to KDE's preferred audio device for certain non-KDE apps that try to use a specific device
Summary: PulseAudio streams are moved to KDE's preferred audio device for certain non-...
Status: RESOLVED WORKSFORME
Alias: None
Product: kdemultimedia
Classification: Unmaintained
Component: general (show other bugs)
Version: unspecified
Platform: Debian stable Linux
: NOR normal
Target Milestone: ---
Assignee: Multimedia Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-09 02:09 UTC by Chris
Modified: 2022-12-30 05:24 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris 2016-09-09 02:09:03 UTC
Using KDE Platform Version 4.14.2.

When OpenAL Soft <http://openal-soft.org/> is set to use PulseAudio for output, and is configured to allow output streams to be moved during playback, KDE will see the stream it creates and forcefully move it to the preferred audio device as set in the System Settings. This occurs even when the stream is explicitly connected to a specific device by the app, and even if the app was previously moved to a different device through kmix or pavucontrol. This effectively makes it impossible for any OpenAL app to open a specific device when playback is movable, and instead has to be moved onto the desired device after starting.

Other applications, such as Firefox, do not exhibit this behavior. They will use the device that they were last set to use through pavucontrol. Unloading module-device-manager from PulseAudio works around the problem by preventing KDE from handling specific devices, though is obviously less than ideal.

Ideally, what I'd like to see happen, is that if an app has OpenAL Soft connect to the default device, KDE can manage it and keep it on the preferred audio device as the device list changes, but when it connects to a specific device, it leaves it on that device. Or failing that, to simply not ever move it on its own.

Reproducible: Always

Steps to Reproduce:
1. Install a recent Git version of OpenAL Soft (with PulseAudio support, and with examples if you don't have another OpenAL app to run). A recent release may work too, but the examples in those versions don't have an option to play on a specific device.
2. Configure OpenAL Soft to allow PulseAudio streams to move, by creating or editing ~/.alsoftrc and adding the lines:
[pulse]
allow-moves = true
3. Run an app using OpenAL Soft, such as the alstream example, using different output devices.

Actual Results:  
Playback is immediately moved to the preferred audio device set in KDE's System Settings.

Expected Results:  
Playback stays on the requested device.

I'm the author of OpenAL Soft, and tracked the problem of OpenAL apps not staying on the devices they were opened on, to KDE, as it only happens when KDE has the ability to manage PulseAudio app devices (making the stream unmovable, or unloading module-device-manager, prevents the problem; changing KDE's preferred audio device while the app is running causes playback to move to the new preferred device too). I do not see anything on OpenAL Soft's side that would cause KDE to do this, and can't see any difference between Firefox and OpenAL Soft apps (as seen by PulseAudio's sink-input properties) that could trigger this behavior.
Comment 1 Michael Reiher 2018-09-05 10:12:57 UTC
This sounds like it could be the cause for a problem we found in our browser app running in Chromium/Chrome. It allows the user to set the sound devices (input/output, through Chome/WebRTC API). However the setting doesn't seem to have any effect when running under KDE. 

I'm not entirely sure how this all plays together and which component in the end is responsible to reroute the audio stream. But it looks like KDEs sound-whatever could play a role.

If the user (in an application) explicitly sets a device it should never be rerouted! This should only happen for a generic default device, if something like that exists.

So would be great to see this fixed. It screws up audio device selection in 3rd party applications and lets them look broken. 

And it's hard to figure out for the user what is going on. And even if you found out, when you plug and unplug devices that configuration seems to be forgotten and needs to be redone every time.
Comment 3 Justin Zobel 2022-11-30 05:28:13 UTC
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Comment 4 Bug Janitor Service 2022-12-15 05:13:18 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 5 Bug Janitor Service 2022-12-30 05:24:03 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!