Open borine opened 1 year ago
borine
commented
1 year ago 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.
pv
commented
4 months ago 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 {48, 96, 144} depending on number of connections.
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 3*wMaxPacketSize-3 is the magical size. I guess the idea in Core v5.4 Vol 4 Part B §2.1.1 Table 2.1 is that with these payload sizes you can just stuff audio to USB, and USB isochronous transport takes care of feeding it at exactly the right rate to the controller. (You can calculate the HCI and audio data rates with different number of connections, and verify the numbers are equal.)
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 or~ some 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.