-
Notifications
You must be signed in to change notification settings - Fork 189
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Broken mSBC on USB devices using Alt-6 (Intel) #622
Comments
PR #550 is an attempt to fix this issue. If you are experiencing problems with HFP mSBC performance when using a Realtek or Intel Bluetooth adapter, please do try out that branch. |
Maybe some more information: Another use case for #550 would be SCO CVSD connections to multiple devices, with USB controllers. The kernel changes the altsetting on the fly depending on the number of active SCO connections, and it appears USB controllers want PCM audio payload size of exactly These are the payload sizes that result to total HCI data rate = USB data rate -- the HCI data rate depends on the payload size due to the 3 byte header per packet, and the Apparently, when the manufacturers implemented the mSBC support, they continued requiring the same magical sizes for ALT 1 / 3 even though there's no particular rationale for it any more... |
At present, BlueALSA always uses a fixed chunk size of 24 bytes when writing mSBC encoded audio to the SCO socket with a USB adapter. The value of 24 bytes is determined by the USB isochronous endpoint being set to Alternate 1.
Back in about 2020 Realtek introduced USB bluetooth adapters that require Linux to use Alternate Setting 3, and also Intel introduced some USB adapters (actually M.2 devices, for example the Intel AX200, USB id 8087:0029 ) that require Alternate setting 6. Alternate Setting 3 has a chunk size of 72 bytes, and Alternate Setting 6 has a chunk size of 60 bytes.
So BlueALSA is not able to maintain a steady data stream for mSBC with
Realtek USB adapters orsome Intel USB (M.2) adapters, because it uses a chunk size of 24 bytes for all USB adapters (except Realtek) regardless of the USB Alternate setting.There is some historical discussion relating to this in issue #400. However, to clarify the current situation and create a reference point for users experiencing problems with HFP using Realtek or Intel adapters, this issue has been created to replace that one to reduce the number of old comments that need to be digested.
There is no easy or efficient way for BlueALSA to know the actual Alternate setting in use by the USB endpoint underlying the BT SCO socket. Both Pipewire and PulseAudio have a workaround that allows them to determine the correct write chunk size by checking the size of incoming chunks read from the socket; but BlueALSA's architecture makes it difficult to apply that workaround. So the the current situation is that BlueALSA simply does not support mSBC on these adapters.
[EDIT]
Commit 142307d (included in release 4.1.1 or later) introduced a workaround specifically for Realtek USB adapters. Since that commit, playback using mSBC on Realtek USB is working. Commit 0cf3cce (in current sources, not yet in any releases) fixed capture using mSBC with Realtek USB adapters. So the current BlueALSA sources now do support mSBC on Realtek USB devices. However the Intel Alternate Setting 6 adapters are still not yet supported.
The text was updated successfully, but these errors were encountered: