No matter which Bluetooth headphones I use, there is a periodic problem with audio continuity. My understanding is that Bluetooth codec is inefficient at preparing audio for transmission. Not using advanced CPU instructions, or just badly written. Does anyone else experience the same problem?
When making such a statement it is suggested that you include the source of the information you used to make that ‘understanding’. Without a source that others can confirm the information (or misinformation) it becomes nothing more than FUD. (Fear, Uncertainty, Disinformation (or Doubt))
I have no bluetooth problems and I might note that bluetooth can easily be blocked or disrupted by lots of things in the area. Simply moving around may allow walls, furniture, hardware, wiring, etc. to interrupt the low power signals used.
Yea, well, if audio is played to headphones without Bluetooth, there is no lag. When playing audio to the headphones with Bluetooth the audio is unstable. Does that look like FUD for you? I am not hiding behind walls or furniture. The distance between laptop and my head is roughly 40cm.
There is other FUD (fear, uncertainty and doubt) about Bluetooth problems reported here on Discourse.
- Sound interruptions in bluetooth headphones (F36, unanswered)
- Bluetooth Audio (BCM4360), Fedora 39, stutters, reduced quality (F39, unanswered)
- Problem bluetooth in new kernel update: 6.5.5-200.fc38 (F38)
- Bluetooth Audio becomes stuttering while downloading or heavy use in network data via ethernet (F35)
So lotsa peoples spreading FUD. It will help them spread less FUD and more useful info if there were instructions how to debug the issue.
My comment was based on the ‘my understanding’ in that statement. Obviously something triggered the ‘understanding’ and it is important to be clear in what is meant.
You might also realize that audio is one of those areas where ‘everyone’ has preferences in hardware and sound quality so what works for 95% may not be acceptable for the remaining 5%.
Different hardware and different configs with software makes a lot of differences in performance. Codecs, the actual audio file, the app in use, the devices – both speaker or headphone as well as audio card – and many other things including load on the computer all affect audio quality. For some things there is as yet no solution, for others they just work.
Your links are great and they reveal just a small part of the audio picture with linux in general and fedora specifically.
I tried a bluetooth connection between two Fedora 39 systems with pipewire, with two old laptops, and did not observe a problem with the codecs offered, so this more or less rules out CPU power problem. Pipewire offers SBC, AAC and Opus codecs, and the old SBC codec has worst quality (common sense, I cannot hear it anymore), and uses the highest tranfer rate. In “pavucontrol”, tab configuration, you can switch codecs depending on what the headphone support. May be another setting works better if the headphone supports it.
The command “pw-top” indicates whether there are errors in the pipewire system. If any, I would not know how to tackle it, unfortunately. There are a few tunable parameters like quantum, but I never touched this.
Other problems are that Wifi and bluetooth share frequency bands, so if your system supports it, you can try to switch wifi to 5GHz band.
I looks like the problem with Bluetooth is much deeper. I checked journalctl logs and there clear signs of defects in Bluetooth code. Not sure how exploitable it is, but I would say if that is, it should be a pretty major ($1000) bounty (RCE).
Dec 03 04:33:05 systemd[1]: Reached target bluetooth.target - Bluetooth Support.
Dec 03 04:33:05 systemd[1093]: Reached target bluetooth.target - Bluetooth.
Dec 03 04:33:06 wireplumber[4460]: RFCOMM receive command but modem not available: AT+CHLD=?
Dec 03 04:33:06 wireplumber[4460]: RFCOMM receive command but modem not available: AT+CCWA=1
Dec 03 04:33:06 wireplumber[4460]: RFCOMM receive command but modem not available: AT+NREC=0
Dec 03 04:33:07 wireplumber[4460]: Failed to register battery provider. Error: org.freedesktop.DBus.Error.UnknownMethod
Dec 03 04:33:07 wireplumber[4460]: BlueZ Battery Provider is not available, won't retry to register it. Make sure you are running BlueZ 5.56+ with experimental >
Dec 03 04:33:07 kernel: input: YS-BT9953 (AVRCP) as /devices/virtual/input/input30
Dec 03 04:33:07 systemd-logind[904]: Watching system buttons on /dev/input/event16 (YS-BT9953 (AVRCP))
Dec 03 04:33:09 audit[890]: ANOM_ABEND auid=4294967295 uid=0 gid=0 ses=4294967295 subj=system_u:system_r:bluetooth_t:s0 pid=890 comm="bluetoothd" exe="/usr/libe>
Dec 03 04:33:09 kernel: show_signal: 46 callbacks suppressed
Dec 03 04:33:09 kernel: traps: bluetoothd[890] general protection fault ip:561366d40f34 sp:7ffeb7655350 error:0 in bluetoothd[561366d2b000+dd000]
Dec 03 04:33:09 audit: BPF prog-id=289 op=LOAD
Dec 03 04:33:09 audit: BPF prog-id=290 op=LOAD
Dec 03 04:33:09 audit: BPF prog-id=291 op=LOAD
Dec 03 04:33:09 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@0-558260-0 comm=">
Dec 03 04:33:09 systemd[1]: Created slice system-systemd\x2dcoredump.slice - Slice /system/systemd-coredump.
Dec 03 04:33:09 systemd[1]: Started systemd-coredump@0-558260-0.service - Process Core Dump (PID 558260/UID 0).
Dec 03 04:33:10 systemd-coredump[558261]: [🡕] Process 890 (bluetoothd) of user 0 dumped core.
Module /usr/lib64/libudev.so.1.7.7 (deleted) from rpm systemd-254.5-2.fc39.x86_64
Module /usr/lib64/libcap.so.2.48 (deleted) from rpm libcap-2.48-7.fc39.x86_64
Module /usr/lib64/libsystemd.so.0.37.0 (deleted) from rpm systemd-254.5-2.fc39.x86_64
Module sixaxis.so from rpm bluez-5.70-3.fc39.x86_64
Module libzstd.so.1 from rpm zstd-1.5.5-4.fc39.x86_64
Module liblzma.so.5 from rpm xz-5.4.4-1.fc39.x86_64
Module liblz4.so.1 from rpm lz4-1.9.4-4.fc39.x86_64
Module libpcre2-8.so.0 from rpm pcre2-10.42-1.fc39.2.x86_64
Module libdbus-1.so.3 from rpm dbus-1.14.10-1.fc39.x86_64
Module libglib-2.0.so.0 from rpm glib2-2.78.1-1.fc39.x86_64
Module bluetoothd from rpm bluez-5.70-3.fc39.x86_64
Stack trace of thread 890:
#0 0x0000561366d40f34 avdtp_unref (bluetoothd + 0x37f34)
#1 0x0000561366d32d65 setup_unref.lto_priv.0 (bluetoothd + 0x29d65)
#2 0x0000561366d3acb1 transport_cb (bluetoothd + 0x31cb1)
#3 0x0000561366d71cea accept_cb.lto_priv.0 (bluetoothd + 0x68cea)
#4 0x00007f13e55e2e5c g_main_context_dispatch_unlocked.lto_priv.0 (libglib-2.0.so.0 + 0x5be5c)
#5 0x00007f13e563ddd8 g_main_context_iterate_unlocked.isra.0 (libglib-2.0.so.0 + 0xb6dd8)
#6 0x00007f13e55e4447 g_main_loop_run (libglib-2.0.so.0 + 0x5d447)
#7 0x0000561366d2fc2d main (bluetoothd + 0x26c2d)
#8 0x00007f13e537814a __libc_start_call_main (libc.so.6 + 0x2814a)
#9 0x00007f13e537820b __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2820b)
#10 0x0000561366d30d75 _start (bluetoothd + 0x27d75)
ELF object binary architecture: AMD x86-64
If somebody is interested to follow this path, BleedingTooth: Linux Bluetooth Zero-Click Remote Code Execution | security-research here is the previous analysis of Bluetooth holes.
Yes, that looks like a crash in bluetoothd. Probably an ordinary bug and not something dangerous which was reported in 2020 and probably fixed in mean time. Remarkable are the deleted modules, which indicate an update while bluetoothd is running. They stay invisible on disk until they are not referenced anymore, but I do not know whether this could introduce some inconsistency in the system. For the rest the only thing you can do, I’m afraid, is reboot, try again and file a bug report with all data to help the developers to fix the problem.