Summary: KDE Connect Bluetooth backend causes audio crackling/stuttering in Bluetooth headset (A2DP) under PipeWire Description: After updating to KDE Connect 25.12.0-1 on EndeavourOS (Arch Linux-based, KDE Plasma 6.5.4), enabling the Bluetooth backend in KDE Connect settings causes severe audio crackling and stuttering when playing audio through a Bluetooth headset (Sony WH-1000XM4) using A2DP profile with AAC codec in PipeWire. The same issue occurs with the two previous versions, 25.11.80 and 25.11.90. The issue did not occur with the previous version (KDE Connect 25.08.3-2). Downgrading to 25.08.3-2 resolves the problem completely while keeping the Bluetooth backend enabled. Symptoms: - Audio starts normally for a few seconds, then crackling persists for an extended period (cycle of normal → heavy crackling → normal). - The issue occurs only when the Bluetooth backend is enabled in KDE Connect settings (Backends → Bluetooth checked). - Disabling the Bluetooth backend immediately resolves the crackling (audio becomes stable, though other KDE Connect features over Wi-Fi remain functional). - Switching to SBC codec reduces crackling but degrades sound quality significantly. - No issues with HSP/HFP profiles (mono, low quality). Workaround: - Disabling the Bluetooth backend in KDE Connect GUI (Settings > Backends > uncheck Bluetooth) or setting disabled_providers=BluetoothLinkProvider in ~/.config/kdeconnect/config fully resolves the issue while keeping the latest KDE Connect version. - Downgrading KDE Connect to 25.08.3-2 allows using the Bluetooth backend without issues. This behavior resembles Bug 415976 (KDE Connect increasing Bluetooth buffer size leading to laggy sound in PulseAudio), but occurs in a modern PipeWire environment. It appears the Bluetooth backend interferes with PipeWire's Bluetooth audio buffering or scheduling. Steps to Reproduce: 1. Update to KDE Connect 25.12.0-1 on EndeavourOS/Arch Linux with PipeWire. 2. Pair a Bluetooth headset (e.g., Sony WH-1000XM4) and set A2DP Sink with AAC codec. 3. Open KDE Connect settings → Backends → Enable Bluetooth. 4. Play audio (e.g., music or video). 5. Observe crackling after a few seconds. 6. Disable Bluetooth backend → Crackling stops immediately. Environment: - OS: EndeavourOS (up to date as of December 2025) - KDE Plasma Version: 6.5.4 - KDE Frameworks Version: 6.21.0 - Qt Version: 6.10.1 - KDE Connect: 25.12.0-1 - Audio server: PipeWire (with WirePlumber) - Bluetooth headset: Sony WH-1000XM4 (firmware up to date) - Codec: AAC (default/high priority) Additional Information: - No relevant errors in journalctl for PipeWire/WirePlumber/Bluetooth during the issue. - Tested multiple buffer/quantum adjustments in PipeWire – no effect when Bluetooth backend is enabled. - Issue started after KDE Applications update to 25.12.0. This significantly impacts usability for users relying on high-quality Bluetooth audio. A fix to prevent the Bluetooth backend from interfering with A2DP audio buffering would be appreciated.
After the recent update from 25.12.0-1 to 25.12.1-1, even when the "bluetooth" backend of the kdeconnect is disabled, it still "constantly" uses bluetooth and causes bluetooth audio to stutter. The previous update to 25.12.0-1 was also causing the same issue, but it was possible to fix it by disabling the bluetooth backend from within the settings. Now that setting is probably being ignored by the service itself. Weird. There should be a way to disable the bluetooth backend of kdeconnect entirely.
Comment from original reporter (myself): I can confirm the same regression in 25.12.1-1. Disabling the Bluetooth backend (via Settings > Backends > Bluetooth unchecked, or disabled_providers=BluetoothLinkProvider in ~/.config/kdeconnect/config) no longer works. The interference with PipeWire A2DP audio (choppy/stuttering playback on WH-1000XM4) occurs unconditionally after connecting Bluetooth headphones. Downgrading to 25.08.2-2 completely resolves the issue (stable, no stuttering). Temporary workaround: Manually restart kdeconnectd after connecting headphones, but this is not practical for daily use. Affected versions: 25.12.1-1 (EndeavourOS) Workaround: Pin kdeconnect to 25.08.2-2 with IgnorePkg in pacman.conf Please prioritize this regression, as it makes Bluetooth audio unusable with KDE Connect running. Thank you!
(In reply to TSUKUMO Akito from comment #2) > Comment from original reporter (myself): > > I can confirm the same regression in 25.12.1-1. > Disabling the Bluetooth backend (via Settings > Backends > Bluetooth > unchecked, or disabled_providers=BluetoothLinkProvider in > ~/.config/kdeconnect/config) no longer works. > The interference with PipeWire A2DP audio (choppy/stuttering playback on > WH-1000XM4) occurs unconditionally after connecting Bluetooth headphones. > > Downgrading to 25.08.2-2 completely resolves the issue (stable, no > stuttering). > Temporary workaround: Manually restart kdeconnectd after connecting > headphones, but this is not practical for daily use. > > Affected versions: 25.12.1-1 (EndeavourOS) > Workaround: Pin kdeconnect to 25.08.2-2 with IgnorePkg in pacman.conf > > Please prioritize this regression, as it makes Bluetooth audio unusable with > KDE Connect running. > Thank you! I am also on EndeavourOS but i am on a RPI5 so it is the "arm" version (based on arch arm, using the same package repository). Are you also on a RPI? If that is the case, maybe our weak bluetooth chip can't handle multiple querries and streams at the same time and stalls. But kdeconnect should not "constantly" querry for bluetooth devices i would assume. I mean it must stop at some point, but as our experience proves it, it just doesn't.
Can confirm that this bug happens on Fedora Asahi Remix 43 (aarch64, Apple Silicon), using version 25.12.1. IMO, this is of major severity.
Happening to me as well, on Fedora Asahi Remix 43 with KDE Connect 25.12.1.
(In reply to ledo.kane from comment #3) > (In reply to TSUKUMO Akito from comment #2) > > Comment from original reporter (myself): > > > > I can confirm the same regression in 25.12.1-1. > > Disabling the Bluetooth backend (via Settings > Backends > Bluetooth > > unchecked, or disabled_providers=BluetoothLinkProvider in > > ~/.config/kdeconnect/config) no longer works. > > The interference with PipeWire A2DP audio (choppy/stuttering playback on > > WH-1000XM4) occurs unconditionally after connecting Bluetooth headphones. > > > > Downgrading to 25.08.2-2 completely resolves the issue (stable, no > > stuttering). > > Temporary workaround: Manually restart kdeconnectd after connecting > > headphones, but this is not practical for daily use. > > > > Affected versions: 25.12.1-1 (EndeavourOS) > > Workaround: Pin kdeconnect to 25.08.2-2 with IgnorePkg in pacman.conf > > > > Please prioritize this regression, as it makes Bluetooth audio unusable with > > KDE Connect running. > > Thank you! > > I am also on EndeavourOS but i am on a RPI5 so it is the "arm" version > (based on arch arm, using the same package repository). Are you also on a > RPI? If that is the case, maybe our weak bluetooth chip can't handle > multiple querries and streams at the same time and stalls. But kdeconnect > should not "constantly" querry for bluetooth devices i would assume. I mean > it must stop at some point, but as our experience proves it, it just doesn't. @ledo.kane Thanks for the info and the suggestion. Just to clarify: I'm actually running EndeavourOS on a **MacBook Pro 2018** (Intel x86_64) with the **linux-t2** kernel (not ARM / RPi5). So the weak Bluetooth controller theory might not fully apply here, but it's still interesting that you're seeing the same symptoms on RPi5 (ARM). For me, the issue definitely started/regressed with KDE Connect 25.12 series and is reproducible even when the Bluetooth backend is supposedly disabled (in 25.12.1). Downgrading to 25.08.3-2 or forcing a kdeconnectd restart right after connecting the headset remains the only reliable workarounds so far. Thanks again for testing and reporting — more confirmations from different hardware help a lot.
(In reply to Lélahel Hideux from comment #4) > Can confirm that this bug happens on Fedora Asahi Remix 43 (aarch64, Apple > Silicon), using version 25.12.1. IMO, this is of major severity. @Lélahel_Hideux Thank you for confirming and for marking it as major severity — I agree it's quite disruptive. Interesting that it's also affecting Apple Silicon (Asahi Fedora). This seems to be happening across both x86_64 and aarch64 now.
(In reply to Alessandro from comment #5) > Happening to me as well, on Fedora Asahi Remix 43 with KDE Connect 25.12.1. @Alessandro Thanks for the additional confirmation on Fedora Asahi Remix. Looks like the regression in 25.12 is pretty widespread. Hopefully this gets more attention from the KDE Connect maintainers soon.
Can confirm on IMac Intel i9 9600k to and also with Sony 1000XM5. very annoying as it costed me 1 Mo of discovery and installing linux all over and over
Confirmed this is happening on: kdeconnect 25.12.1 Operating System: Fedora Linux Asahi Remix 42 KDE Plasma Version: 6.5.5 KDE Frameworks Version: 6.22.0 Qt Version: 6.9.3 Kernel Version: 6.16.8-400.asahi.fc42.aarch64+16k (64-bit) Graphics Platform: Wayland Processors: 8 × Apple Firestorm (M1 Pro), 2 × Apple Icestorm (M1 Pro) Memory: 30.9 GiB of usable RAM Graphics Processor 1: Apple M1 Pro Graphics Processor 2: llvmpipe Product Name: Apple MacBook Pro (16-inch, M1 Pro, 2021) KDE Connect's use of Bluetooth interferes with Bluetooth Audio. In previous versions I could disable KDE Connect's use of Bluetooth with the checkbox in KDE Connect Settings. However now it seems this checkbox is ineffective. Symptoms: bluetoothctl --monitor hci0 type 1 discovering on hci0 type 1 discovering off hci0 type 1 discovering on hci0 type 1 discovering off [repeats every ~10 seconds] Bluetooth audio is cut out while bluetooth is discovering. For me, running `killall kdeconnectd` caused the bluetooth discovery loop to stop, and bluetooth audio to resume uninterrupted.
want to add that im on cachyos. but same on fedora, ubuntu, so it is a cross platform thing
Same on Fedora 43. After uninstalling kde-connect. The issue is gone. These packages were uninstalled: Package changes: -0:fuse-sshfs-3.7.5-1.fc43.x86_64 -0:kde-connect-25.12.1-1.fc43.x86_64 -0:kde-connect-libs-25.12.1-1.fc43.x86_64 -0:kdeconnectd-25.12.1-1.fc43.x86_64 -0:kf6-kpeople-6.22.0-1.fc43.x86_64 -0:libfakekey-0.3-25.fc43.x86_64 -0:openssh-askpass-10.0p1-6.fc43.x86_64
Hi! Just wanted to confirm same thing happening on Arch Linux. It also interferes with 2.4Ghz wifi when it puts bluetooth in discovery mode, causing high latency spikes and network slowdowns. Solution is downgrading KdeConnect.
+1 also happens to me on cachyOS and killing kdeconnect in terminal fixes the issue made a account just to bring attention to this
(In reply to Svetlana from comment #14) > +1 also happens to me on cachyOS and killing kdeconnect in terminal fixes > the issue > > made a account just to bring attention to this thx for your reply. Are you having this on mac or non mac hardware too?
(In reply to Martin from comment #15) > (In reply to Svetlana from comment #14) > > +1 also happens to me on cachyOS and killing kdeconnect in terminal fixes > > the issue > > > > made a account just to bring attention to this > > thx for your reply. Are you having this on mac or non mac hardware too? This is on non Mac hardware (5800X3D CPU)
(In reply to Svetlana from comment #16) > (In reply to Martin from comment #15) > > (In reply to Svetlana from comment #14) > > > +1 also happens to me on cachyOS and killing kdeconnect in terminal fixes > > > the issue > > > > > > made a account just to bring attention to this > > > > thx for your reply. Are you having this on mac or non mac hardware too? > > This is on non Mac hardware (5800X3D CPU) (In reply to Martin from comment #15) > (In reply to Svetlana from comment #14) > > +1 also happens to me on cachyOS and killing kdeconnect in terminal fixes > > the issue > > > > made a account just to bring attention to this > > thx for your reply. Are you having this on mac or non mac hardware too? On my side it's also happening on non mac hardware too (Ryzen 7 7840hs). Before finding out it's kdeconnect issue, I assumed it's related to wifi hardware/drivers so I swapped my MT7922 for Intel AX210 card. I can confirm same thing happening on both cards.
(In reply to danilo.cvijetic10 from comment #17) > (In reply to Svetlana from comment #16) > > (In reply to Martin from comment #15) > > > (In reply to Svetlana from comment #14) > > > > +1 also happens to me on cachyOS and killing kdeconnect in terminal fixes > > > > the issue > > > > > > > > made a account just to bring attention to this > > > > > > thx for your reply. Are you having this on mac or non mac hardware too? > > > > This is on non Mac hardware (5800X3D CPU) > > (In reply to Martin from comment #15) > > (In reply to Svetlana from comment #14) > > > +1 also happens to me on cachyOS and killing kdeconnect in terminal fixes > > > the issue > > > > > > made a account just to bring attention to this > > > > thx for your reply. Are you having this on mac or non mac hardware too? > > On my side it's also happening on non mac hardware too (Ryzen 7 7840hs). > Before finding out it's kdeconnect issue, I assumed it's related to wifi > hardware/drivers so I swapped my MT7922 for Intel AX210 card. I can confirm > same thing happening on both cards. Thats good, as if it solely had been Apple Hardware they would never make it a priority Thanks all for contributing to this thread.
Hey, on my side (Fedora 43) this is only happening after: https://invent.kde.org/network/kdeconnect-kde/-/commit/2f62b712c7cb8415dde784621ab667a992af856f However, it seems to me that this just uncovers the underlying issue, because the problem only occurs when device discovery is started via `QBluetoothServiceDiscoveryAgent`. If I'm not mistaken, before this commit, `mServiceDiscoveryAgent->start()` never gets triggered, because `BluetoothLinkProvider::connectTimer` was never started, whereas afterwards `AsyncLinkProvider::connectTimer` is started right away.