Open tobiasBora opened 3 years ago
I also had severe problems with bluetooth stuff, but i did not have time to research this problem as much as you did. I am also interested in the progress here.
For people interested, note that pipewire seems to solve all these issues (and is has much more bluetooth profiles, jack support is transparent... just great) :
However, it's not yet perfect: the audio keys does not work anymore (so I need to use pavucontrol to change volume), and (at least in KDE) the systray volume icon is gone.
EDIT: installing plasma-pa (kmix may also work) solve both of these two issues. As explained here, plasma-pa
is now added automatically since today. Also, to get pactl
commands, you can install pavucontrol
as a package, is should not interfere with pipewire.
For bluetooth to work somewhat decently with pulseaudio you AFAIK need a separate daemon that handles the bluetooth headphone protocol: hardware.bluetooth.hsphfpd.enable = true;
With pipewire this Just Works since it has the same functionality built into its pipewire-pulse module.
Since 21.05 I also experience the same issue. I don't know why I wasn't experiencing the same as you in 20.09
With pipewire this Just Works since it has the same functionality built into its pipewire-pulse module. I will look into pipewire, thank you!
The situation is horrible and I know no way to debug it. I'm not able to switch spotify or firefox or anything to the bluetooth headset, unless I turn the whole card off. Of course I lose the internal microphone so when I have to make a call I need to re-enable it and it automatically switches to the speakers, defeating the purpose of having the headset in the first place.
pavucontrol presents me with fake controls, showing that I can switch the stream to another output but when I try to do it it does literally nothing
It won't solve pavucontrol's issues, but moving to latest pipewire (I'm on unstable) solved all these problems. It even made jack programs much easier to use… I won't go back to pulseaudio! I guess we should at least write a warning for people using pulseaudio that bluetooth is barely usable, recommending to move to pipewire.
I marked this as stale due to inactivity. → More info
I've started having similar issues after switch from 23.05 to 23.10
everything worked fine on 23.05, but after switch - pulseaudio just sometimes won't detect bluetooth headset. Bluetooth pairing works fine, but pulseaudio just does nothing. it is a laptop, so i can put it to sleep and wake it, after that behaviour would change to one of 3 possible states, and that state will persist until another sleep-wake procedure or reboot: 1) as before, pulseaudio ignores bt device 2) pulseaudio recognizes device in low quality mode with mic 3) pulseaudio recognizes device as normal high quality device
sometimes pulseaudio crashes once after sleep-wake before changing "mode", but other than that I don't see any errors in logs
Are you able to try with pipewire instead?
I've tried simplest pipewire setup from nixoswiki
security.rtkit.enable = true;
services.pipewire = {
enable = true;
alsa.enable = true;
alsa.support32Bit = true;
pulse.enable = true;
# If you want to use JACK applications, uncomment this
#jack.enable = true;
};
and it seem to be working fine. (not counting some kde bugs like not auto switching to headphones sometimes, other times switching, but still displaying the wrong icon in tray)
But what is a little bit of a dealbreaker is that firefox(flatpak) while playing videos eats up 1.5-2 times more CPU compared to setup with pulseaudio. And it's not pipewire process, but firefox that's eating extra cpu. (at least as seen by htop) Not sure what's happening here.
As for pulseaudio situation - there is more detailed description with journalctl
logs here in discourse. (for example, i cannot reproduce p.2 from my prev post any more - can consider that to be a fluke; and device always working after sleep, just never from the first attempt...)
I wonder if this is due to pipewire being able to use shorter quantums (i.e. lower latency) than pulseaudio. That would likely make firefox wake up more frequently to send more data to the audio API. With pipewire you can use pw-top
to monitor this. If you want lower CPU use in exchange for slightly worse latency you should be able to configure the minimum quantum to something larger.
I've conducted a proper test later and found no statistically significant difference in CPU usage.
There seem to be a fluke in my initial brief testing (i rushed with it) - maybe firefox just happened to do something else at that time, but i suspect I've incorrectly compared 2 different scenes of the same video, so compression load on CPU was different.
So then pipewire seem to be the way to go.
Describe the bug
When I was running older NixOs (I'd say 20.03) on KDE Plasma, it was very easy to plug a bluetooth headset: I just connect it via the icon in the bar, and the sound was automatically moved to bluetooth. In case some applications was stuck on the computer, I could still go into pavucontrol and manually move them easily.
Now, the process is much more complicated. After connecting to the bluetooth, the computer is still blocked on internal output. If I go in pavucontrol, my bluetooth headset appears (BT H2):![image](https://user-images.githubusercontent.com/2164118/118949442-88021d80-b959-11eb-80e4-f2bfa14481cf.png)
but when I click on it I'm automatically moved back to intern audio:![image](https://user-images.githubusercontent.com/2164118/118949517-9bad8400-b959-11eb-9cff-b997bdc82e16.png)
Then, I need to kill pulseaudio to be able to select the output:
but now my application is not listed anymore in the list:
so I need to refresh my page (here I was playing a youtube video on firefox): now the application appears again, and plugged with BT H2:![image](https://user-images.githubusercontent.com/2164118/118949815-e3341000-b959-11eb-984a-c6322053eefc.png)
But it's not enough! For some reasons, whenever I reconnect/disconnect my headset (or when I change the output profile), it mutes all outputs:
so I need to unmute it first to hear some sound:
and still, this is not enough: the sound has extremely poor quality: usually the bluetooth devices have 2 modes, one for high quality without microphone, and one for low quality but with microphone. Since I upgraded recently to latest unstable (I was on
5ff6700bb82
before, and now I'm on83d907fd760
), it selects the low quality output, and I can't even change it back: it's written "unavailable" while I had no issues in the last 5 years with this headset...So now I'm stuck with low quality sound...
To Reproduce Steps to reproduce the behavior:
Expected behavior I expect a simple "plug and listen" procedure, I expect to be able to change sinks in pavucontrol, I expect to have high quality sound available.
Additional information
In my
configuration.nix
, here are some relevant lines:Metadata Note that my system is configured to build using commit
83d907fd760
."x86_64-linux"
Linux 5.10.37, NixOS, 21.05pre-git (Okapi)
yes
yes
nix-env (Nix) 2.4pre20210503_6d2553a
"nixos-unstable-21.05pre289339.83d907fd760, nixos-21.03pre267299.5ff6700bb82"
"local-nixos-unstable-21.05pre283883.d235056d6d6, home-manager, local-nixpkgs-unstable-21.03pre267409.f5daa8ab31f, nixos-20-03-20.03.3324.929768261a3, test, nixos-unstable-21.03pre250162.34ad166a830"
/nix/var/nix/profiles/per-user/root/channels/nixos
Maintainer information:
@ttuegel @NixOS/qt-kde