Playback jitters with Samsung Galaxy Buds2 Pro over LE Audio #713
Comments
The RX is pretty much the same but the TX of the second connection is falling behind (@pv not sure how you plot them together though, might be a good addition to btmon --analyze), also there seems to be a considerable about of packets failing to be delivered before the presentation delay (which I assume is 40ms?). |
|
Thanks for having a look @Vudentz. What'd be your suggestion here? Presumably, this'd need addressing at the controller (AX210) level? |
Yes, something at link-layer is not quite right it seems. |
|
Where'd be the best place to report this? |
I talking to our (Intel) firmware folks, looks like it is not a good idea to have the ISO interval at 10ms if the HID is at 7.5ms since their intervals would eventually collide, now where we put such a policy may be the problem, because it is pipewire that is selecting 10ms interval perhaps it should check if there is anything else already connected, like HID, that said when it is the opposite we would have to adjust the HID to 10ms if there is already an ISO at 10ms. |
According to some folks we shall prefer 7.5ms whenever possible since its better for coexisting scenarious and it does have the added benefit of being lower latency as well. |
|
Well pipewire can choose 7.5ms as well, https://gitlab.freedesktop.org/pvir/pipewire/-/commit/6510420dd12546021c5d4924fd1a85a91ca5bf90 and maybe @tlvince can try to see if that helps. If the sound server has to choose 10ms in some cases and 7.5ms in other cases depending on what else is connected, then it sounds like BlueZ should decide or at least suggest the right value to the sound server. Maybe |
Yeah, we can do something like that, the tricky part is if the peripheral asks to change the ACL interval later, well perhaps we should reject that. |
|
The immediate issue (of playback breaking up) has certainly improved with https://gitlab.freedesktop.org/pvir/pipewire/-/commit/6510420dd12546021c5d4924fd1a85a91ca5bf90. I can't reliably trigger it by moving the mouse as I could before. However, the general usability is flakey. My initial experience was the ear buds often would fail to connect and/or be listed as a playback device/sink. Restarting I'd have to do more testing to isolate different factors - I'm unsure how much of this would have been introduced by https://gitlab.freedesktop.org/pvir/pipewire/-/commit/6510420dd12546021c5d4924fd1a85a91ca5bf90 if at all. |
According to Intel people this is better for their hardware. Link: bluez/bluez#713
|
linux-firmware just got new FW for Intel AX chips, maybe these work better? |
|
With linux-firmware 4f3022dc1f90e29705d892996b89a9cec3e183c4 (which includes the AX210 update), I experience similar behavior. Playback works for a few minutes until the ear buds disconnect/reconnect. (A secondary issue - the microphone does not show up in GNOME sound settings, but does in Some logs (I'll get capture some debug logs later): |
|
slightly off topic |
|
Yes, we can add support for SWB in Pipewire, afaics it uses same esco modes as msbc so might not require changes on kernel side. I'll need to get a test device though to make it easier. EDIT: done https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/1856 |
|
Gave it another test. Same overall behaviour as before - playback's fine for a minute or two, intermittently with stutters, until one or both of the ear buds eventually disconnects. Debug logs: Versions:
|
Looks like things starts to go wrong when scan is enabled after connecting the mouse, they it goes into a pretty bad latency over time: They do seem to be in sync, it just the TX latency is way too big. |
Retransmission and Maximum Latency are rather big though, @pv how do you choose these parameters? This is sort of high reliability territory which I don't think it is recommended for the general use cases, we should probably go for balanced for general use which is more inline with the testing presets e.g. 48_1_1 latency 15 ms rtn 5. |
|
We set RTN and latency to the preferred values the device suggests in its ASE. I think this device produced at least in its first firmware revision broken sound if the small latency values from BAP were used. (This happens when BlueZ fails to report the preferred QoS values due to the API issue in SelectProperties; as a workaround I changed also the fallback values to the high-reliability ones, but I think in the case here the values come from the device.) Here: |
You meant the values from https://github.com/bluez/bluez/blob/master/doc/org.bluez.MediaEndpoint.rst#dict-qos-readonly-optional-iso-only-experimental? Are they reporting PreferredRetransmissions as 13? |
TX latency can grow if there is clock drift between controller and host, and controller clock runs a bit slower. Or (which looks like occurred here) if the controller leaves packets in the queue without sending them. If the TX latency / packet queue depth is made visible to userspace (without monitor), Pipewire can rate match to compensate for clock drift and dropouts like this. (This would be useful to have also for A2DP in principle.) This sort of matching is also made with ALSA and is necessary as sound card clocks are not necessarily in sync with host or with each other, or with machines over network etc. EDIT: actually, not sure they help in this case since latency growth here appears fast enough for Pipewire to get EAGAIN from the socket, in which case we stop sending for a while (500ms) to avoid losing sync between the earbud CIS. In principle Core spec has the TX Sync command but I don't see how it can be used for TX synchronization without direct access to controller clock --- and AFAIK we can only communicate with it over HCI... On the disconnections: I have not seen disconnections in my tests (over long times), but I don't have other devices connected than these earbuds. In the above dumps, the disconnections are as They come from controller (don't know why they occur). |
Yes, see #713 (comment) where I added now the values the ASE reports |
|
Tried it here: It indeed does return RTN as 13 and latency as 95?? Even though I requested Balance Latency/Reliability (0x02), now the problem seems to be that we have no means to communicate this back to the endpoint without triggering another round of QoS settings, and to be honest this is sort of bogus because they are not a range but a specific value and at this point I don't think the headset can possible tell what the source is going to transmit, so I think it is actually best to ignore these and try to come up with the best settings per context/target latency. |
|
For me, 48_5_1 on this device produces broken audio while 48_5_2 works (as do the "preferred" QoS values). The smaller SDU, 48_1_1 and 48_3_1 both work. |
|
Earfun is even worse in picking up preferred settings: RTN 15 and Latency 400ms, I think they are just hardcoding the values for the worse case, instead of given their best guess for the target latency, the spec is also pretty vague in how these values should be interpreted, but so far these don't give me high hopes they are going to be useful. |
|
I guess this means it has to be done exactly like what Android does, as the manufacturers probably are going to test with that, and anything else is crapshoot. |
|
@tlvince you can try the smaller SDU/RTN/latency values in case it changes something https://gitlab.freedesktop.org/pvir/pipewire/-/commit/f95bbce59a62b29887b335f669bcfae6a32ac20e Also try if changing input stream from 48kHz to 16kHz helps: https://gitlab.freedesktop.org/pvir/pipewire/-/commits/lc3-workaround-3 (for me, this makes a faint buzzing sound that comes from the left earbud during playback to go away) ... or maybe both: https://gitlab.freedesktop.org/pvir/pipewire/-/commits/lc3-workaround-4 |
Ive been thinking on contact the peripheral companies because it makes sense to expose their stack to more implementation making it more robust in the process, perhaps we could create a database of devices and then describe their status since at some point that shall reach the manufactorer. |
|
Unfortunately the same symptoms (playback until one ear bud drops) persisted with all three options:
Could you verify my system's using the correct pipewire builds from those? These (and all earlier tests) we done with buds firmware R510XXU0AWI2. I've just noticed there's an update R510XXU0AXA2, which I'll try. |
|
Same with R510XXU0AXA2 and smaller latency + 16khz: smaller-latency-16khz-xa2-firmware.btsnoop |
|
Here's another sample dump without the keyboard and mouse connected in case it shows anything useful. Playback's fine with these disconnected (and was before any of the previous changes). |
|
@tlvince: those btsnoop seem to all use the larger latency. You can check the transport configuration in bluetoothctl with In btmon you should see |
|
Thanks. An old build was still use in my last test. All 3 fared better this time. Force 48_1_1 for LC3f95bbce59a62b29887b335f669bcfae6a32ac20e: smaller-latency.btsnoop bluetoothctl transport.show2nd attempt, I got a disconnection soon after restarting 3rd attempt was mostly stable until a bit of break up around event ~80000, smaller-latency-3.btsnoop prefer 16khz input for LE Audio
bluetoothctl transport.showcombined
bluetoothctl transport.show |
|
Hit another disconnect with the combined 48_1_1 + 16KHz branch after ~1 hour of playback. Unfortunately don't have a btsnoop dump, but repeated pipewire stderr |
That means there is still some race where tearing down the old CIG does not complete before bluez tries to set it up again. If you have the bluetoothd logs from before that error it might tell something. |
|
Unfortunately no logs for that one. Will re-test next week. |
Don't believe QoS values recommended by the device, which may be suboptimal. Instead, pick the values from the BAP v1.0.1 Table 5.2. Link: bluez/bluez#713
Per pipewire #3762, I experience frequent jitters/short breaks in playback using the Samsung Galaxy Buds2 Pro over LE Audio/bap. I can reproduce this reliably when a LE mouse (MX Master) is connected at the same time and is moved.
Thanks to analysis from @pv:
I've tried a few different buffer sizes on the pipewire side to no avail.
intel/ibt-0041-0041.sfi151-42.23The text was updated successfully, but these errors were encountered: