NixOS / nixpkgs

Nix Packages collection & NixOS
MIT License
17.34k stars 13.58k forks source link

Since 20.09(?) Pulseaudio in KDE Plasma really hard to use with Bluetooth: need to kill pulseaudio, unmute, and since recently high fidelity output not available anymore #123784

Open tobiasBora opened 3 years ago

tobiasBora commented 3 years ago

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

but when I click on it I'm automatically moved back to intern audio: image

Then, I need to kill pulseaudio to be able to select the output:

pkill pulseaudio

but now my application is not listed anymore in the list:

image

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

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:

image

so I need to unmute it first to hear some sound:

image

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 on 83d907fd760), 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...

image

So now I'm stuck with low quality sound...

To Reproduce Steps to reproduce the behavior:

  1. Upgrade to latest unstable on KDE Plasma
  2. Connect a bluetooth headset
  3. Observe that the sound still goes out of the internal card, and that the bluetooth can't be configured to use the high quality A2DP sink.

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:

  # Enable sound.
  sound.enable = true;
  hardware.pulseaudio.enable = true;
  # Enable jack support in pulseaudio
  # hardware.pulseaudio.package = pkgs.pulseaudio.override { jackaudioSupport = true; };
  hardware.pulseaudio.package = pkgs.pulseaudioFull;
  # Enable bluetooth
  hardware.bluetooth.enable = true;

  # Enable the KDE Desktop Environment.
  services.xserver.displayManager.sddm.enable = true;
  services.xserver.desktopManager.plasma5.enable = true;

  # Use vlc backend instead of gstreamer to have access to pdf in okular
  services.xserver.desktopManager.plasma5.phononBackend = "vlc";

Metadata Note that my system is configured to build using commit 83d907fd760.

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute: plasma5, bluetooth, pulseaudio
# a list of nixos modules affected by the problem
module: hardware.bluetooth, hardware.pulseaudio, services.xserver.desktopManager.plasma5

@ttuegel @NixOS/qt-kde

tfc commented 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.

tobiasBora commented 3 years ago

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) : image

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.

jansol commented 3 years ago

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.

zarelit commented 3 years ago

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

zarelit commented 3 years ago

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

tobiasBora commented 3 years ago

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.

stale[bot] commented 2 years ago

I marked this as stale due to inactivity. → More info

pedohorse commented 9 months ago

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

peterhoeg commented 9 months ago

Are you able to try with pipewire instead?

pedohorse commented 9 months ago

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

jansol commented 9 months ago

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.

pedohorse commented 9 months ago

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.