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.

Diffstat

1 files changed, 9 insertions(+), 12 deletions(-)