[kdemultimedia] [Bug 368472] New: PulseAudio streams are moved to KDE's preferred audio device for certain non-KDE apps that try to use a specific device

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[kdemultimedia] [Bug 368472] New: PulseAudio streams are moved to KDE's preferred audio device for certain non-KDE apps that try to use a specific device

Peter Simonsson-2
https://bugs.kde.org/show_bug.cgi?id=368472

            Bug ID: 368472
           Summary: PulseAudio streams are moved to KDE's preferred audio
                    device for certain non-KDE apps that try to use a
                    specific device
           Product: kdemultimedia
           Version: unspecified
          Platform: Debian stable
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: general
          Assignee: [hidden email]
          Reporter: [hidden email]

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.

--
You are receiving this mail because:
You are the assignee for the bug.
Reply | Threaded
Open this post in threaded view
|

[kdemultimedia] [Bug 368472] PulseAudio streams are moved to KDE's preferred audio device for certain non-KDE apps that try to use a specific device

Peter Simonsson-2
https://bugs.kde.org/show_bug.cgi?id=368472

Michael Reiher <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #1 from Michael Reiher <[hidden email]> ---
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.

--
You are receiving this mail because:
You are the assignee for the bug.
Reply | Threaded
Open this post in threaded view
|

[kdemultimedia] [Bug 368472] PulseAudio streams are moved to KDE's preferred audio device for certain non-KDE apps that try to use a specific device

Peter Simonsson-2
In reply to this post by Peter Simonsson-2
https://bugs.kde.org/show_bug.cgi?id=368472

Yamashita Ren <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #2 from Yamashita Ren <[hidden email]> ---
Could be related to :
https://bugs.chromium.org/p/chromium/issues/detail?id=881396&can=4&q=&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified

--
You are receiving this mail because:
You are the assignee for the bug.