realme earbuds disconnection issue - bluez-alsa

[Asikbct]

Problem

Our speaker functions as an A2DP source, and we need to test connectivity with multiple devices. During testing, we observed connection failures specifically with Realme earbuds. The issue arises when no audio is sent to the Realme headset for a while—at this point, the headset deletes all its transport endpoints and disconnects from our speaker. Even when attempting to reconnect the same headset, the connection fails with a "key missing" error.

One key observation is that this issue does not occur when using PulseAudio for Bluetooth. We suspect that BlueZ-ALSA does not actively monitor or manage the transport endpoint, leaving it idle instead. However, the exact cause of the issue remains unclear.

Reproduction steps

1. Open bluetoothctl.
2. Scan for available devices.
3. Connect to the Realme headset.
4. Keep the connection idle (without playing any audio) for 30 seconds to 1 minute.
5. The headset will delete its transport endpoint and automatically disconnect.
6. Attempt to reconnect the same device—it will fail with a "key missing" error.

Setup

Linux username 5.4.210 #2 SMP PREEMPT Tue Jan 7 17:01:44 IST 2025 aarch64 GNU/Linux

bluealsa --version v4.1.1

/usr/libexec/bluetooth/bluetoothd --version 5.72

aplay --version aplay: version 1.2.1 by Jaroslav Kysela [email protected]

[borine]

@Asikbct are you starting bluealsad with -p hfp-ag or -p hfp-hf ? If so, please can you test without the hfp profile enabled to see if that makes a difference.

The only similar error report I can find is in the Bluez project, see https://github.com/bluez/bluez/issues/419

That one turned out to be a problem in pipewire and pulseaudio, but we should at least test to see if a similar problem exists in the bluealsa rfcomm code.

[borine]

I've just seen an issue in bluez, which is not quite the same as yours, but may be related: https://github.com/bluez/bluez/issues/868 Basically its saying that some speakers will not play A2DP unless the source also has an AVRCP player registered. The solution there is to simply run the bluez mpris-proxy program. So it might be worth trying that too.

[borine]

unless the source also has an AVRCP player

oops! sorry, please ignore my previous comment. I got that completely back-to-front. In that issue the the user is building a bluetooth speaker, not trying to send audio to one. mpris-proxy does nothing useful on a host running bluealsad -p a2dp-source so that is not relevant here.

[borine]

@Asikbct you have not replied to my question about hfp, however as the only similar bug report I can find for Bluez is the one previously referenced which turned out to be caused by HFP RFCOMM message handling by the realme buds, I am assuming that this error is related to that one.

It appears that the realme buds drop both the connection and the pairing information if certain rfcomm messages time out before a response is recieved. In that previous bug report it was because pipewire was not responding to an +IPHONEACCEV message, which pipewire then fixed.

Bluealsa does respond to that particular message, but there may be some other message used by realme to which bluealsa does not respond. My suspicion is that realme is using the +BIND/+BIEV HF indicator feature messages, even though bluealsa has informed it that those messages are not supported. (in which case it is a bug in the realme device). The only way to find out is to see the debug output from bluealsad when the realme earbuds are connected. Could you please supply that debug information?

[Asikbct]

@borine , Sorry for the delayed response.

@Asikbct are you starting bluealsad with -p hfp-ag or -p hfp-hf ? If so, please can you test without the hfp profile enabled to see if that makes a difference.

I don’t start BlueALSA with HFP support — I only enable A2DP source and sink.

I noticed this issue happens only when the DUT connects to the Realme Buds, but the BlueALSA plugin isn’t initialized (no audio stream is started or no sink is registered). In this case, the Realme Buds would disconnect after a while.

Later, I changed the setup to use the PulseAudio plugin. For example, once the DUT connects to the Realme Buds, I immediately initialize the BlueALSA plugin using: pactl load-module module-alsa-sink device=bluealsa

After that, the music source writes audio to the PulseAudio plugin, which redirects it to BlueALSA. In this setup, the connection stays stable, even if no music is played for a long time — the Realme Buds remain connected while idle.

So I’m wondering: Does the Realme Buds expect the remote device (DUT) to register a transport or start audio streaming soon after connection? And if that doesn’t happen, does it treat the connection as incomplete and automatically disconnect or forget the pairing?

[borine]

Does the Realme Buds expect the remote device (DUT) to register a transport or start audio streaming soon after connection?

The Bluetooth specifications do not require that; I have no way of knowing what the realme device is expecting.

You appear to be using both pulseaudio and bluealsa on the same host, and that only adds to the complexity, the number of variables and system states to be investigated. I think if you want to resolve this, you need to completely clear the state of both the DUT and the buds and start afresh with only bluealsa installed, and pulseaudio or pipewire not installed at all. The difficulty is that bluetooth devices cache data to save bandwidth on subsequent connections, and this cache can become invalid if one device is changed. For example changing from pulse to bluealsa after pairing, adding or removing profiles or codecs. If you can re-build your DUT so that neither pulse nor pipewire have ever been installed, and pair with a new realme device that has never been paired with this DUT before, then you will have a clean start and be able to test with bluealsa properly,

[borine]

There is a relevant interesting comment by Pauli Virtanen in a Bluez issue here: https://github.com/bluez/bluez/issues/1064#issuecomment-2585452184 where he states:

some devices have firmware bugs triggered by many endpoints.

Pauli is a major contributor to the Pipewire Bluetooth implementation, and has extensive knowledge and experience of Bluetooth audio.

Now BlueALSA creates many AVDTP endpoints, so perhaps this is a potential cause of this problem with Realme earbuds? Perhaps it might also have been the cause of the problem reported in #666, which was never resolved?

I don't have a workaround for this, so if this is the cause then it may be that such devices simply cannot be used with BlueALSA.

[arkq]

I don't have a workaround for this, so if this is the cause then it may be that such devices simply cannot be used with BlueALSA.

Hmm... that can be easily verified - the logic which ensures that we have at least one extra endpoint registered need to be updated not to do that:

diff --git a/src/bluez.c b/src/bluez.c
index f181512..3298687 100644
--- a/src/bluez.c
+++ b/src/bluez.c
@@ -738,6 +738,9 @@ static void bluez_export_a2dp(
                struct bluez_dbus_object_data *dbus_obj;
                GError *err = NULL;

+               if (index == 1)
+                       break;
+
                const char *path = bluez_get_media_endpoint_object_path(adapter, sep, ++index);
                if ((dbus_obj = g_hash_table_lookup(dbus_object_data_map, path)) == NULL) {

If this will resolve the problem, we can add command line option which will "block" this logic (just like in the patch).

[borine]

@Asikbct This issue has been idle for quite some time now; did you ever manage to test bluealsa with the patch posted by @arkq in the previous comment? If this fixes the problem for the realme buds then it may also be useful for other devices too. Unfortunately I do not have any devices which suffer from this problem, so I am unable to test it myself.