Bluetooth Headset Loses Audio [pw.node: (bluez_output.04_5D_4B_29_06_26.1-80) running -> error (Received error event)]

Thanks for the bug report.

Next time the problem happens please run:

  journalctl -b0 > journal.txt
  lspci -k > lspci.txt
  lsusb > lsusb.txt
  rfkill > rfkill.txt

and attach the resulting text files here.

I don't know if this is the same bug, but now my headset won't reconnect. This has also been happening. I just pair it again and then it works for a while. This time I made your files which are included below.

Thanks for thinking about this.

Rob

Adding the other attachments...

and the lsusb result.

and the rfkill.

This time I tried removing the headset and repairing, but it still would not find the headset. So I turned off Bluetooth and then back on, and it immediately appeared. When I clicked it it connected. (I did not have to click on the headset, then the slider in the box for the headset only.)

Rob

It sounds like the log in comment #3 is now describing a new bug instead of the original bug here. Please ensure you provide a log from when the original bug occurred.

What I can see in the log is that the Realtek kernel driver (and possibly the hardware) has failed just before Bluetooth audio has problems. So it seems likely the issues are originating in the hardware or in the kernel driver and we don't need to track this in pipewire.

Unfortunately the next step I would recommend here would be to try a USB dongle that contains an Intel Wifi+Bluetooth chip instead. I know that's annoying but if the Realtek hardware or kernel driver is buggy then that's something Canonical can't fix.

You might be able to get around the problem in software however, by trying a newer (or even an older) kernel.

Please also try eliminating sources of 2.4GHz interference such as wifi networks. Changing your network and devices to use 5GHz instead should help to avoid interfering with Bluetooth which is around 2.4GHz.

Here is a more recent journalctl (after re-pairing, and connecting successfully so I could watch some youtube. :-)

The original journal goes back to before when I'm sure the original problem was occurring. The interesting thing is that this has been working for a while, and I only noticed the problem fairly recently (probably the last month). The new problem (not reported yet elsewhere) is a different headset and different laptop, but I kind of think I remember it happening on it as well. And this makes me remember that the journal, etc I sent you were on the wrong laptop! So sorry! Let me get you the right ones.

Rob

So sorry! I really messed up. The original laptop is a Fujitsu and the one I did the testing on above was a Thinkpad. Here are the correct files for the original bug.

and the lspci...

and the lsusb...

and rfkill.

Your comment about RFI on 2.4GHz may be right on. I recently got hearing aids (Phonak Marvel M70-R) and they use Bluetooth too. They were on the same ears as my headset. The problems have been happening about as long as I have had the hearing aids. I'll try and do some testing next time to see if I can figure out if they are partly or wholly to blame. It is an intermittent problem.

Thanks. Please ensure you only provide logs from the machine the bug is about in future.

The full set of messages related to this bug seems to be:

Jan 31 22:26:18 t935 wireplumber[1791]: 0x56370f33ca08: error 24
Jan 31 22:26:18 t935 wireplumber[1791]: RFCOMM write error: Connection reset by peer
Jan 31 22:26:18 t935 acpid[876]: input device has been disconnected, fd 18
Jan 31 22:26:18 t935 bluetoothd[885]: src/profile.c:ext_io_disconnected() Unable to get io data for Hands-Free Voice gateway: getpeername: Transport endpoint is not connected (107)
Jan 31 22:26:18 t935 wireplumber[1791]: (bluez_output.04_5D_4B_29_06_26.1-24) running -> error (Received error event)
Jan 31 22:26:18 t935 dbus-daemon[888]: [system] Rejected send message, 0 matched rules; type="method_return", sender=":1.80" (uid=1000 pid=1791 comm="/usr/bin/wireplumber" label="unconfined") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.11" (uid=0 pid=885 comm="/usr/lib/bluetooth/bluetoothd" label="unconfined")
Jan 31 22:26:18 t935 pipewire[1789]: pw.node: (bluez_output.04_5D_4B_29_06_26.1-60) running -> error (Received error event)
Jan 31 22:26:18 t935 gsd-media-keys[2098]: Unable to get default sink

Although sometimes the first couple are missing. So it seems like a full Bluetooth stack issue always starting in bluetoothd (BlueZ). That's not to say it's definitely a software bug because it sounds like the headset might have disconnected to begin with.