Branch: refs/heads/974594 Home: https://github.com/bluez/bluez Commit: 0ae2a2f77f007a43ec075dc13d605851df1d6e4c https://github.com/bluez/bluez/commit/0ae2a2f77f007a43ec075dc13d605851df1d6e4c Author: Pauli Virtanen <pav@xxxxxx> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M src/shared/bap.c Log Message: ----------- shared/bap: handle inverted order of stop ready and disabling->qos DISABLING->QOS transition and Receiver Stop Ready reply may arrive in any order. BAP v1.0.2 (Sec. 5.6.5.1): CIS may be terminated by either side after Receiver Stop Ready has successfully completed. However, when we get the reply, the stream may be in either state. Instead of client detaching the IO on stop ready reply, rely on detaching IO on entering QOS, where Receiver Stop Ready has then necessarily completed. On DISABLING, mark stream io as not connecting, so that it gets detached even if CIS was not yet established. Seen to occur with Samsung Galaxy Buds2 Pro, when it refuses Enable for 32/32kHz duplex on one of the earbuds. To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
