To provide terminal output, copy the text you wish to share, and paste it here, surrounded by three (3) backticks, a.k.a grave accents. Like this:
```
pasted text
```
This will just cause it to be rendered like this:
Portaest sed
elementum
cursus nisl nisi
hendrerit ac quis
sit
adipiscing
tortor sit leo commodo.
Instead of like this:
Portaest sed elementum cursus nisl nisi hendrerit ac quis sit adipiscing tortor sit leo commodo.
Thereby improving legibility and making it much easier for those trying to be of assistance.
Please edit your post accordingly.
All that said, it sounds quite normal to me, as each account pairs on it’s own. And what’s more, I don’t think something a simple as headphones will be able to store multiple pairings.
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
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 and only 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?
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?
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 the audio group, 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.
.
I don’t know if this is the right track - but I don’t know how else to solve this.