Bug 98144 - bluetooth devices are not closed when the user is switched away from the seat
Summary: bluetooth devices are not closed when the user is switched away from the seat
Status: RESOLVED MOVED
Alias: None
Product: PulseAudio
Classification: Unclassified
Component: modules (show other bugs)
Version: unspecified
Hardware: Other Linux (All)
: medium normal
Assignee: pulseaudio-bugs
QA Contact: pulseaudio-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-10-07 14:04 UTC by Felipe Sateler
Modified: 2018-07-30 10:15 UTC (History)
7 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Felipe Sateler 2016-10-07 14:04:40 UTC
Pulseaudio currently closes ALSA devices when it loses access to them when the user switches away from a seat or the session stops being active. Moreover, it doesn't try to claim them when new devices appear.

Bluetooth devices are not similarly closed, which causes issues if there are more than 1 active pulseaudio daemons running on a system (this is common in GNOME desktops: GDM will keep a session with pulseaudio running).

Pulseaudio should probably implement such a collaborative closing for bluetooth devices.


Other sink/sources are probably affected by the same issue.
Comment 1 Daniel van Vugt 2017-07-13 04:13:39 UTC
I wonder; is failure to close the device really the problem? Or is it that the second pulseaudio instance (the user's actual login) has trouble with bluetooth discovery and so never sees the bluetooth device (and thus logs no errors about failing to open it)?
Comment 2 Tanu Kaskinen 2017-07-14 19:12:14 UTC
I haven't looked into this very much, but I would expect both instances to see the bluetooth devices. The communication with bluetoothd happens over D-Bus, and getting a list of devices should succeed for any number of simultaneous clients. It's only setting up the audio transport that can cause conflicts.
Comment 3 Marcin Owsiany 2018-07-08 21:19:16 UTC
I can confirm that the second instance *can* see the device. A common situation (see https://askubuntu.com/questions/765233/pulseaudio-fails-to-set-card-profile-to-a2dp-sink-how-can-i-see-the-logs-and for workarounds people came up with) is that the other (i.e. actual logged in user) session can use the low-quality sink, but not the high-quality A2DP one.
Comment 4 GitLab Migration User 2018-07-30 10:15:33 UTC
-- 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/303.


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.