PulseAudio usually has separate instances for user accounts so other user accounts cannot access potentially sensitive audio channels
But user accounts can be configured as primary and secondary users to share one PulseAudio instance and access the Bluetooth headset
PulseAudio/Examples - Allowing multiple users to share a PulseAudio daemon | ArchWiki
1 Like
Perhaps not the same, but it might be relevant:
Check the section * Dual boot pairing* here:
https://wiki.archlinux.org/title/bluetooth#Pairing
Because, I think it might be this:
To pair devices on dual boot setups you need to change the pairing keys manually on your Linux install, so that they match in both systems.
But instead of Windows and Linux, it’s two users on Linux.
Buuut I don’t use bluetooth, so it’s only an untested and unproven theory.
Thanks for the quick reply’s.
This sounds like it could be the issue - I’ll give it a try and report back.
I’ve been monkeying around with this for a day now. The results are “interesting” 
.
Or, maybe I just don’t get what the default behavior is supposed to be. Hopefully someone can clear that up for me.
I looked at separate bluetooth pairings, but AFAIK the pairings are on a system level and not user level. It doesn’t seem possible to pair the same two units again, once paired.
I set up a shared PulseAudio instance. It worked as described, but that wasn’t the desired effect. I get all audio from all users at the same time, regardless of which account I’m logged in to.
What I wanted, was my headset to work as all other audio devices and only receive input from the current user.
When using any other audio device, this is how it works:
When I switch from account A to account B, audio output stops on built-in and wired audio devices as soon as I reach login screen. Logging in to the account B then resumes audio playback of what it was playing.
What I don’t understand is why PulseAudio treats a wireless headset differently from a wired headset.
I assume that somewhere in udev or logind, there is a rule or script, that stops the audio devices, wouldn’t it be possible to add the bluetooth headset to that list of devices?
AFAIK that means the pairing would have to be system-wide, while the audio server would have to be user-restricted.
Buut, I’m no expert.
Edit:
I don’t know if this is what you’re looking for, but have a look at pasuspender:
$ pasuspender -h
pasuspender [options] -- PROGRAM [ARGUMENTS ...]
Temporarily suspend PulseAudio while PROGRAM runs.
-h, --help Show this help
--version Show version
-s, --server=SERVER The name of the server to connect to
Yes, pairing is system wide. All users can see it, just like my mouse.
But if I plugin a wired headset, that is also system wide. So, I don’t understand why it gets treated differently.
Maybe. But it requires a program argument to run and I’m not quite sure what to give it.
I was thinking, that maybe I can make a udev rule, that seats my headset to the user, just like all the other sound devices.
That’s going to take some reading to figure out 
Like an ex-boss always told me: you’ve got the vision, you’ve got the mission. So there you go. Apparently.
I don’t know if this is the right track - but I don’t know how else to solve this.
I also don’t know. So this is a very good way of learning.
Thank you for confirming that suggestion to share one PulseAudio instance works as described
What I don’t understand is why PulseAudio treats a wireless headset differently from a wired headset
Wired headsets (3.5mm jack and USB) are detected in ALSA as 2 subdevices:
- stereo heaphone output (see
aplay -l) - mono microphone input (see
arecord -l)
PulseAudio uses module-udev-detect to detect output sinks and input sources
Bluetooth has 2 audio profiles:
- stereo headphone output
- mono microphone input + mono headphone output
Linux developers cannot risk making audio work the same as on the other OS because the lawyers for the other OS would
PulseAudio uses module-bluetooth-discover and module-bluetooth-policy to manage switching between Bluetooth profiles
Bluetooth Modules – PulseAudio
What I wanted, was my headset to
work as all other audio devices andonly receive input from the current user
I do not understand this request in the context of what you have described so far. Only one user account can be logged in at a time so only the current user can use and control the Bluetooth microphone input?
Command pasuspender would suspend the PulseAudio server and stop all audio streams, which does not seem to be wanted
Audio sinks and sources could be suspended individually, but the suspended sink/source might remain suspended when switching to the other user account
I can think of 2 other ways to control audio devices that are more likely to get a better result:
-
Disable audio device in PulseAudio by changing audio device profile to Off
Or change to an output-only profile to disable source input or input-only profile to disable sink output
(easy to implement or change in audio control GUI or CLI and each user account can have different profiles in respective user home folders ~/.config/pulse) -
Create a custom module configuration in home folder of the user account you want to exclude some audio devices from
(copy default system configuration /etc/pulse/default.pa to ~/.config/default.pa)
To exclude ALSA devices, remove the section of configuration to load module-udev-detect
To exclude Bluetooth devices, remove the section of configuration to load the 2 Bluetooth models
If you post response to this command to show PulseAudio configuration
pacmd dump
I can work out temporary test commands to test if these are viable
I’m not being clear. It’s a headset, with speakers and mic. What I want, is for both source and sink of the headset to be usable by the current user. Right now they are only available to the first user how connects to the headset.
I’m not sure I understand your suggestions. To me it seems, that in both cases you’re disabling/excluding the device for specific users? Or do you mean you want to disable it, when switching users?
Output:
### Configuration dump generated at Mon Aug 8 13:52:28 2022
load-module module-device-restore
load-module module-stream-restore
load-module module-card-restore
load-module module-augment-properties
load-module module-switch-on-port-available
load-module module-udev-detect
load-module module-alsa-card device_id="0" name="pci-0000_05_00.1" card_name="alsa_card.pci-0000_05_00.1" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes avoid_resampling=no card_properties="module-udev-detect.discovered=1"
load-module module-alsa-card device_id="1" name="pci-0000_05_00.6" card_name="alsa_card.pci-0000_05_00.6" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes avoid_resampling=no card_properties="module-udev-detect.discovered=1"
load-module module-bluetooth-policy
load-module module-bluetooth-discover
load-module module-bluez5-discover
load-module module-dbus-protocol
load-module module-native-protocol-unix
load-module module-gsettings
load-module module-default-device-restore
load-module module-always-sink
load-module module-intended-roles
load-module module-suspend-on-idle
load-module module-console-kit
load-module module-systemd-login
load-module module-position-event-sounds
load-module module-role-cork
load-module module-filter-heuristics
load-module module-filter-apply
load-module module-bluez5-device path=/org/bluez/hci0/dev_30_50_75_D9_17_FA autodetect_mtu=0 output_rate_refresh_interval_ms=500 avrcp_absolute_volume=1
load-module module-cli-protocol-unix
set-sink-volume alsa_output.pci-0000_05_00.6.analog-stereo 0xd92d
set-sink-mute alsa_output.pci-0000_05_00.6.analog-stereo no
suspend-sink alsa_output.pci-0000_05_00.6.analog-stereo yes
set-sink-volume alsa_output.pci-0000_05_00.1.hdmi-stereo 0xd2ee
set-sink-mute alsa_output.pci-0000_05_00.1.hdmi-stereo no
suspend-sink alsa_output.pci-0000_05_00.1.hdmi-stereo yes
set-sink-volume bluez_sink.30_50_75_D9_17_FA.handsfree_head_unit 0x10000
set-sink-mute bluez_sink.30_50_75_D9_17_FA.handsfree_head_unit no
suspend-sink bluez_sink.30_50_75_D9_17_FA.handsfree_head_unit yes
set-source-volume alsa_output.pci-0000_05_00.6.analog-stereo.monitor 0x10000
set-source-mute alsa_output.pci-0000_05_00.6.analog-stereo.monitor no
suspend-source alsa_output.pci-0000_05_00.6.analog-stereo.monitor yes
set-source-volume alsa_input.pci-0000_05_00.6.analog-stereo 0x10000
set-source-mute alsa_input.pci-0000_05_00.6.analog-stereo no
suspend-source alsa_input.pci-0000_05_00.6.analog-stereo yes
set-source-volume alsa_output.pci-0000_05_00.1.hdmi-stereo.monitor 0x10000
set-source-mute alsa_output.pci-0000_05_00.1.hdmi-stereo.monitor no
suspend-source alsa_output.pci-0000_05_00.1.hdmi-stereo.monitor yes
set-source-volume bluez_sink.30_50_75_D9_17_FA.handsfree_head_unit.monitor 0x10000
set-source-mute bluez_sink.30_50_75_D9_17_FA.handsfree_head_unit.monitor no
suspend-source bluez_sink.30_50_75_D9_17_FA.handsfree_head_unit.monitor yes
set-source-volume bluez_source.30_50_75_D9_17_FA.handsfree_head_unit 0x000
set-source-mute bluez_source.30_50_75_D9_17_FA.handsfree_head_unit no
suspend-source bluez_source.30_50_75_D9_17_FA.handsfree_head_unit yes
set-card-profile alsa_card.pci-0000_05_00.1 output:hdmi-stereo
set-card-profile alsa_card.pci-0000_05_00.6 output:analog-stereo+input:analog-stereo
set-card-profile bluez_card.30_50_75_D9_17_FA handsfree_head_unit
set-default-sink bluez_sink.30_50_75_D9_17_FA.handsfree_head_unit
set-default-source bluez_source.30_50_75_D9_17_FA.handsfree_head_unit
### EOF
One other thing, before I go experimenting. I’ve noticed that my primary user (mho) is in the audio group (and some others), none of the other users (test) are. I don’t think that’s correct. Can someone comment on that?
grep mho /etc/group
wheel:x:998:mho,test
audio:x:996:mho
input:x:994:mho
lp:x:991:cups,mho
storage:x:987:mho
users:x:984:mho
network:x:90:mho
power:x:98:mho
mho:x:1000:
How do you switch to 2nd user ?
- logoff 1st user, then login 2nd user at the same seat
- suspend 1st user, then login 2nd user at the same seat
- login 1st user at seat0, then login 2nd user at seat1
Andreas
Good question. With the Gnome “switch user” menu.
I presume it does number 2 or 3?
Switching may then only suspend user1, and may be your user1 keeps holding a lock on “his” headset 
You could try:
- Login user1, use headset
- Logout User1
- Login User 2, use headset ???
That works if I also reconnect the headset - see my first post.
Thank you for the clarification. I was going in the wrong direction to disable headset for one user
I’ve noticed that my primary user (
mho) is in the audio group (and some others), none of the other users (test) are. I don’t think that’s correct
I agree that is not correct (and this might be related to the problem with switching users)
PulseAudio - Configuration Files - ArchWiki
There is usually no need to add your user to theaudiogroup, as PulseAudio uses [udev] and logind to give access dynamically to the currently “active” user. Exceptions would include running the machine headless so that there is no currently “active” user.