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.
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)?
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.
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.
-- 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.