bluez-alsa
bluez-alsa copied to clipboard
arkq
No sound with HFP with USB BCM20702A1 adapter
I'm using a BCM20702A1 USB BT interface attempting to get HFP working on some Bose QC-35 headphones. A2DP is working, but aplay with SCO just produces silence of the appropriate length. The bluealsa log doesn't indicate any errors. arecord never receives any data and hangs.
I've tested with another BT adapter, BCM4345C5, which is connected over a UART (with wifi on sdio) and that does work in HFP mode, both playback and recording. Audio quality is vastly improved over a Macbook Air mid-2012 that doesn't seem to support wide band voice in HFP.
It seems like this is very similar to #258, but that was fixed with a commit to configure broadcom adapters to use the hci interface for audio instead of an I2S interface. It does appear that the code in fix is active:
bluealsa: D: sco.c:166: Checking Broadcom internal SCO routing
bluealsa: D: sco.c:172: Current SCO interface setup: 1 2 0 1 1
bluealsa: D: sco.c:200: Created SCO dispatcher [ba-sco-dispatch]: hci0
Once SCO playback is started, I get these messages from the kernel:
Bluetooth: hci0: Device does not support ALT setting 6
Bluetooth: hci0: urb 00000000a9df4129 submission failed (90)
Bluetooth: hci0: urb 00000000a9df4129 submission failed (90)
Bluetooth: hci0: sending frame failed (-90)
The last two messages then repeat constantly.
It might be possible that this USB BT adapter just doesn't support mSBC. Apparently ALT mode 6 is supposed to be used for mSBC over USB.
I disabled mSBC support in bluealsa, and then this time I remember to run the recompiled src/bluealsa instead of the system installed bluealsa. With only 8kHz CVSD sound available, it worked. Audio quality is poor of course.
It would be nice if there was a way to discover if the BT adapter can do WBS or not. I also see a hack to get a realtek chipset to use alt1 for mSBC. Perhaps that can work.
Doesn't really seem like a bluealsa bug, unless those -90 errors are making there way back to bluealsa and it is ignoring them.
Hacking the btusb driver to use alt1 instead of alt6 was able to produce audio!
But it sounds bad. Too loud and with a hiss in the background. It sounds better with the correctly functioning bt adapter. So I suspect there is still some problem.
Bluetooth: hci0: Device does not support ALT setting 6
Yes, that requirement for USB was introduced in Linux 5.8 - see https://github.com/Arkq/bluez-alsa/issues/343
The Bluetooth Core spec does require Alt6 for mSBC : it is the only way to get correct SCO timing on isochronous links with USB. Previously the btusb module was completely unaware of mSBC, so USB adapters gave very poor mSBC audio quality as SCO packets were fragmented or dropped. Not all USB adapters have Alt6 implemented. I too have a BCM20702A1 adapter and can confirm that it does not have Alt6.
Unfortunately, bluealsa would need to be modified to use mSBC with kernels >= 5.8; at present it uses the wrong socket MTU (24 bytes). It should be 60 bytes. It is not a trivial change because btusb does not provide a "capabilities" API so I don't know how bluealsa can determine whether mSBC support is available or not. Trying to deduce from the reported kernel version/revision is just not reliable.
Is it not possible to use another alt setting? There is now a patch from Realtek that uses alt 1 for one of their devices in the kernel.
For socket MTU, there is a pending patch from chromeos that provides a ioctl to get the MTU from SCO socket. Would that solve the problem?
In the Bluetooth Core Specification, Volume 4, section 2.1.1, Table 2.1: USB Primary firmware interface and endpoint settings, the "Recommended" Host Controller endpoint setting for mSBC voice is Alternate 6. So hardware manufacturers that follow the recommendations will use that. Its possible that a specific Realtek adapter ignores that recommendation, but it would then require a vendor-specific "quirk" in the driver for correct communication between the driver and the firmware. I think that in general, a USB BT adapter will require the driver to use Alternate Setting 6 for correct timing of mSBC SCO packets across the HCI. Adapters that do not implement Alt6 are not (in general) capable of supporting mSBC.
The chromeos patch looks promising. The Linux btusb module currently reports either the controller buffer size or a fixed "quirk" value of 64 for the socket MTU. Neither is usefui to an application. An application needs to know the USB mtu (48 for CVSD, 60 for mSBC) and it would appear on a quick reading of the patch you link above that it will (finally!) implement that.
I'm not sure that the application will yet be correctly informed when mSBC is not available, but at least when it is available then the correct MTU of 60 will be reported. In addition, the correct MTU of 48 for CVSD should also be reported and that would simplify the coding for bluealsa (and pulseaudio).
So possibly proper Linux support for USB mSBC is coming soon (hurrah), But at present (IMHO) the best advice for bluealsa is to use only CVSD on USB adapters. UART adapters should work quite well with mSBC (but bluealsa still lacks packet-loss-concealment, so requires an error-free bluetooth baseband link for glitch-free audio).
it would then require a vendor-specific "quirk" in the driver for correct communication between the driver and the firmware.
That would be the quirk flag BTUSB_USE_ALT1_FOR_WBS that is set for Realtek adapters.
But my real question was why settings other than alt 6 can't work. Isn't it possible to use multiple smaller packets to achieve the necessary data rate?
It would be nice if there was a way with the ALSA device specification to select NBS and CVSD even if WBS is supported, in cases where it doesn't work. Yes one can recompile with mSBC disabled, but a runtime select per device would be nice. Especially for people who just install a distro package.
There is runtime selection, but without any convenient tool. You can use D-Bus call directly. Do as follows:
gdbus call --system -d org.bluealsa \
-o /org/bluealsa/hci0/dev_1C_48_F9_9D_81_5C/hfpag/source \
-m org.bluealsa.PCM1.SelectCodec CVSD '{}'
Correct object path you can find by issuing this:
gdbus call --system -d org.bluealsa -o /org/bluealsa -m org.bluealsa.Manager1.GetPCMs
The list of available codecs query with:
gdbus call --system -d org.bluealsa \
-o /org/bluealsa/hci0/dev_1C_48_F9_9D_81_5C/hfpag/source \
-m org.bluealsa.PCM1.GetCodecs
Reference: https://github.com/Arkq/bluez-alsa/blob/master/doc/bluealsa-api.txt#L44
But my real question was why settings other than alt 6 can't work. Isn't it possible to use multiple smaller packets to achieve the necessary data rate?
well, they can work, as evidenced by Realtek, but it requires cooperation from the firmware which is invariably a proprietary binary blob.
USB isochronous links are "clocked" at 1 millisecond. How much data can be packed into a single transfer depends on the allocated bandwidth for the endpoint, which in turn is determined by the "Alternate" setting. The examples in the Bluetooth Core spec section referenced in previous comment explain the consequences for SCO quite well. If you read the spec and do the math, you find that Alt-1 gives 24 bytes per HCI packet, Alt-6 gives 60 bytes.
Now it just happens that an mSBC frame is 60 bytes, so Alt-6 is the most efficient choice and is recommended by the Bluetooth SIG.
Now imagine you choose Alt-1. You have to fragment 60 bytes into chunks of 24 bytes. If the controller has a large enough buffer, it can read 5 USB frames (120 bytes of payload) and assemble them into 2 mSBC frames. If the buffer is not large enough (a typical value for USB adapters that do not have Alt-6 is just 64 bytes) then it will fail. Maybe Realtek use large buffers, or maybe they implement a circular buffer. I don't know. But I do know from experience that using a socket MTU of 24 for mSBC with USB adapters and Alternate 1 does give extremely poor results; and using a larger MTU can cause the driver and/or firmware to lock up completely.
So the issue is that the firmware, only implementing up to alt 5 with 49 byte packets, probably does not have a buffer large enough to assemble a full 60 byte mSBC frame nor the logic to assemble multiple iso slots into a single frame even if it did have the space.
The datasheet for the CYW20702 does have a section on WBS, but only over the PCM interface.
■ On-chip SmartAudio® technology: The CYW20702 can perform Subband-Codec (SBC) encoding and decoding of linear 16 bits at 16 kHz (256 kbps rate) transferred over the PCM bus.
I wonder if it would be possible to use non-transparent SCO mode to send PCM, as in CVSD, but get the chip to encode to mSBC? Or maybe that only works over the PCM interface. It would probably require some secret vendor specific command to enable.
It might be vendor specific, but BlueALSA already uses vendor specific HCI command to "fix" configuration for Boradcom chips. The same setup might work for Cypress, after Cypress acquired Broadcom (patch is not in the master branch, though). So, switching to PCM interface is not a problem. But then, where should I write PCM data? Where is this PCM interface exposed in Linux?
The PCM interface is a separate hardware interface (different pins on the chip package) and not part of the USB interface. So for external plug-in USB adapters it is not accessible. With on-board designs it may be wired to some GPIO pins, in which case you would need an ALSA driver to present the chip to the kernel as a sound card. However, most PC designs, I think, do not connect these pins at all, so you would need a soldering iron to get access!
so you would need a soldering iron to get access!
Yeah, basically that was my point :)
In theory one could connect an I2S DAC or ADC directly to the PCM interface on the BT chip and transfer the audio directly without the CPU being needed. Maybe a BT headset does this, but I've never seen it done in a device I've worked on, which have all run Linux (or VxWorks). It takes more pins. You need a spare I2S interface on the SoC. Bitbanging I2S over a GPIO wouldn't be feasible in Linux, since the data and frame clock needs to be synced to the MCLK which is probably about 2-8 MHz and good luck bitbanging a 4 MHz clock in Linux.
Well, long ago one could do that in kernel space. But the GPIO layer has gotten a lot slower since then.
But my thought was not using the PCM interface, but rather the BRCM20702A's ability to do the mSBC encoding itself. Maybe it's possible to send uncompressed 16 kHz audio over a USB non-transparent SCO pipe and have it compressed in the chip.
If you read the spec and do the math, you find that Alt-1 gives 24 bytes per HCI packet, Alt-6 gives 60 bytes.
I've now read lots of specs, but I'm not finding this math. Alt-1 for 24 bytes appears to be derived from 9 bytes/packet * 3 packets/frame - 3 bytes HCI header. I don't see where the 3 packet/frame comes from. The BRCM20702A is a FS device. Every spec I've seen seems to be clear that FS devices can request iso packets up to 1023 bytes and at most 1 packet per frame. If it was a HS device, then it's allowed iso packets up to 1024 bytes and up to 3 packets per microframe.
Is that 24 byte MTU only applicable to HS "High Bandwidth" endpoints that allow 3 packets per microframe? And thus does not apply to the BRCM20702A.
If that's the case, then it seems like that ChromeOS patch isn't right, as it assumes 3 packets. It also seems like assuming the alt modes have the "recommended" sizes isn't really correct either and it should be checking the wMaxPacketSize field of the endpoint descriptor to get the real packet size and number limit.
I got it working on the BRCM20702A adapter.
btusb must be modified to place the adapter into an alt mode 1 or 2 for transparent SCO. blue-alsa must use a socket MTU of (packetsize * 3 - 3) bytes. In alt1 this results in 27 byte URBs that fit in exactly 3 alt-1 iso packets of 9 bytes. In alt2 it results in 51 bytes in 3 packets of 17 bytes. Then it works.
Audio sounds the same as mSBC with a UART based BT adapter. 16 KHz mono over WBS is considerable louder than the same audio, also 16 kHz, over A2DP(SBC), but perhaps that is an issue with the QC35's DSP or volume setting effect in A2DP vs HSP.
I tried other alt mode and mtu combinations, but everything else results in silence. I tried 15 bytes so it would take exactly 2 alt mode 1 packets and 33 bytes so it would take exactly 4, but like the holy hand grenade of antioch, four packets shalt thou not send, neither send thou two, excepting that thou then proceed to send three. I didn't try 42 bytes, as five packets is clearly right out.
Alt mode 2 works, again with the MTU set for exactly 3 packets.
In alt mode 3, a three packet MTU would be 72 bytes. This results in "bluealsa: E: SCO write error: Invalid argument" errors. I tried a 47 byte mtu, for 2 packets, but that just produces silence.
@xyzzy42 I think that's an impressive piece of work. If there's any way you could persuade the btusb developers to take note and implement this upstream that would be a fantastic contribution.
I got another USB BT adapter, this one with a Realtek RTL8167B chip. One would think, since Realtek are the ones who provided the patch to try alt mode 1, that it would work, but no. This adapter is missing alt mode 6 too. In alt mode 1 it appears bluealsa must be configured to use a 24 byte MTU. Any other MTU results in no audio. There is sound, but it's very broken. Constantly stuttering. I can get alt 2 to produce sound with a 48 byte MTU, like with the brcm adapter, but the audio is even more broken up than with alt 1. There seems to be a bug with the adapter's driver that causes a kernel panic if the module is unloaded and reloaded. So I haven't tested it as much because it's such a pain.
I think I'll make a patch to make the fallback to alt 1 not realtek specific. It seems clear that the current code has no chance of working for adapters without alt 6. So far, all non-realtek adapters that do not support alt 6 do work with alt 1. Out of a sample size of one adapter. But it makes more sense to to me to have the logic be try alt 6, then try alt 1, and if an adapter is discovered that doesn't work that way, but does work another way, then make a quirk for that adapter.
try alt 6, then try alt 1, and if an adapter is discovered that doesn't work that way, but does work another way, then make a quirk for that adapter.
I second that idea. It's just a shame that the original patch that introduced Alt-6 usage for Linux 5.8 didn't do it that way. If btusb would also report a SCO socket MTU that was useful to an application (i.e. the value(s) you have calculated) then I would be very happy :smiley:
Ordered two more BT USB adapters Friday, free Amazon delivery arrived Saturday, pretty impressive. Almost impossible to find out what chipset an adapter uses though. I want to find the elusive alt mode 6.
Realtek RTL8821C. Also no alt 6 support. Does work at alt 1 with 24 byte MTU. Unlike RTL8167B, sound is not all broken up.
And a CSR8510 adapter too. Same as above.
So out of two Realtek, one Broadcom, and one CSR adapter: zero support alt mode 6. All produce audio with 24 byte MTU at alt 1. One Realtek has bad sound, seems to be no way to fix it (short of adapter's fw).
I also see from btmon that SCO data RX occurs when using the alsa sink. I guess HFP can only do bidirectional sound? But what is interesting is that the packet size for RX appears to independent of the TX packet size. I wonder where this is set? Is it up the to bt adapter how it chooses to send the eSCO link's data over USB? If that's the case, then maybe it choosing 24 bytes for Rx is a good indication of what size should be used for TX too.
I also see from btmon that SCO data RX occurs when using the alsa sink. I guess HFP can only do bidirectional sound?
It all depends on the remote device logic. HFP/HSP is bidirectional, but headset or phone is not required to send any data. You can use two bluealsa-enabled devices to communicate to each other, and you might use only one direction at a time (if you like). But for the real case scenario, headset almost always sends microphone data, so if SCO link is established, you will get RX even though you are using ALSA in a playback mode.
But what is interesting is that the packet size for RX appears to independent of the TX packet size. I wonder where this is set? Is it up the to bt adapter how it chooses to send the eSCO link's data over USB? If that's the case, then maybe it choosing 24 bytes for Rx is a good indication of what size should be used for TX too.
Once I thought about such solution, but the problem is that RX is not guaranteed to be there. So, such a solution would be a heuristic at best.
The patch https://lore.kernel.org/patchwork/patch/1265703/ is shown as "accepted" which I guess, means it will soon appear in the mainline kernel tree? So then it becomes a matter of applying BTUSB_USE_ALT1_FOR_WBS to the driver info for a particular device in order to get btusb to use Alt 1 for mSBC on that device instead of trying (and failing) with Alt 6. Hopefully It won't be too long before this flag is added to all appropriate devices. Then at least we should be back in the same state as before Alt 6 support was first introduced !
The patch https://lore.kernel.org/patchwork/patch/1303071/ is shown as "superseded". I don't know what that means, but I guess we will have to wait a little longer for that to be accepted. When it is, then SCO_OPTIONS (or the newer BT_SNDMTU/BT_RCVMTU) should reveal the correct MTU for the application to use.
So It seems that we are still in a waiting game for btusb to implement the functionality needed by SCO audio, but at least development is heading in the right direction now and hopefully 2021 will see the desired result.
The ALT1_FOR_WBS patch went into the kernel in v5.9-rc1, as commit 461f95f04f19, so it is already in 5.9 kernel. I think the quirk is unneeded. The patch is from Realtek, so by default they only want it to apply to Realtek hardware. They would not even ask, "Is this something that applies to all USB BT adapters?"
Superseded means a new series has replaced it. In this case, it is v3 of that series at (https://marc.info/?l=linux-bluetooth&m=159971791610689&w=2). For some reason I can't find that series on patchwork.
I think the quirk is unneeded
if (btusb_find_altsetting(data, 6)) {
data->usb_alt6_packet_flow = true;
new_alts = 6;
} else if (test_bit(BTUSB_USE_ALT1_FOR_WBS, &data->flags)) {
new_alts = 1;
} else {
bt_dev_err(hdev, "Device does not support ALT setting 6");
}
My reading of the above is that without the quirk, btusb will report an error if the adapter does not support Alt6; with the quirk it will use Alt1 instead. So, I think, every adapter that is to use Alt1 for mSBC requires the quirk to be added in the driver info table.
In the revised second patch you have linked above, in addition to fixing the SCO MTU, the following hunk removes the need for the quirk to be included in the device_info table:
+ if (btusb_find_altsetting(data, 1)) {
set_bit(BTUSB_USE_ALT1_FOR_WBS, &data->flags);
- else
+ hdev->sco_mtu = hci_packet_size_usb_alt[1];
+ } else
bt_dev_err(hdev, "Device does not support ALT setting 1");
So when/if that patch is accepted into mainline, bluealsa (and pulseaudio) will have what they need for mSBC on a USB bus.
The only outstanding issue is, how does an application know if that patch is applied to the running kernel?
The only outstanding issue is, how does an application know if that patch is applied to the running kernel?
I think that it will not be necessary to detect it. We might assume that for mSBC via USB, this patch is a prior requirement (hence kernel => x.x.x). If user knows, that the driver reports invalid MTU (kernel version is below this number and patch is not backported), there might be a command line flag to use fixed bluez-alsa built-in MTU.
I wanted to check to see if I'm experiencing the same issue. The profiles I am able to use are a2dp, hfp(mic) but hfp(speaker) doesn't play the audio.
When I try to play the sound clip using the command aplay -v -D bluealsa:DEV=...,PROFILE=sco sound.wav.
This is the output from bluealsa debug
bluealsa: D: ../../src/dbus.c:59: Called: org.bluealsa.Manager1.GetPCMs() on /org/bluealsa
bluealsa: D: ../../src/dbus.c:59: Called: org.bluealsa.PCM1.Open() on /org/bluealsa/hci1/dev_.../hfpag/sink
bluealsa: D: ../../src/ba-transport.c:976: New SCO link: ...: 20
bluealsa: D: ../../src/hci.c:132: SCO link socket MTU: 20: 64
bluealsa: D: ../../src/msbc.c:72: Initializing mSBC encoder/decoder
bluealsa: D: ../../src/ba-transport.c:801: PCM resumed: 16
bluealsa: D: ../../src/ba-transport.c:829: PCM drained: 16
bluealsa: D: ../../src/ba-transport.c:835: PCM dropped: 16
bluealsa: D: ../../src/ba-transport.c:835: PCM dropped: 16
bluealsa: D: ../../src/ba-transport.c:1018: Closing PCM: 16
bluealsa: D: ../../src/msbc.c:72: Initializing mSBC encoder/decoder
bluealsa: D: ../../src/msbc.c:72: Initializing mSBC encoder/decoder
bluealsa: D: ../../src/sco.c:328: Releasing SCO due to PCM inactivity
bluealsa: D: ../../src/ba-transport.c:994: Closing SCO: 20
bluealsa: D: ../../src/msbc.c:72: Initializing mSBC encoder/decoder
I also get this error code in the kernel.
[116266.433721] Bluetooth: hci1: SCO packet for unknown connection handle 42
[116266.433723] Bluetooth: hci1: SCO packet for unknown connection handle 42
[116349.282347] Bluetooth: hci1: SCO packet for unknown connection handle 42
[116349.282350] Bluetooth: hci1: SCO packet for unknown connection handle 42
[116349.282351] Bluetooth: hci1: SCO packet for unknown connection handle 42
[116349.282352] Bluetooth: hci1: SCO packet for unknown connection handle 42
Please let me know if you need any information to debug further.
What kernel version? Is the bluetooth adapter USB based?
Run lsusb -v, find your bluetooth adapter, and then look at the Interface Descriptors that appear under it, they have lines like these (only some lines shown):
Interface Descriptor:
bInterfaceNumber 1
bAlternateSetting 1
bInterfaceProtocol 1 Bluetooth
Endpoint Descriptor:
Transfer Type Isochronous
wMaxPacketSize 0x0009 1x 9 bytes
What's the highest AlternateSetting and MaxPacketSize it goes up to?
Thanks for the help!
I am running kernel version 5.4.0-56-generic and yes it is USB based I tried the onboard but it didn't support the mic codec I believe.
Here's the output for the AlternateSettings/MaxPacketSize.
Device Descriptor:
Configuration Descriptor:
Interface Descriptor:
bAlternateSetting 0
Endpoint Descriptor:
wMaxPacketSize 0x0010 1x 16 bytes
Endpoint Descriptor:
wMaxPacketSize 0x0040 1x 64 bytes
Endpoint Descriptor:
wMaxPacketSize 0x0040 1x 64 bytes
Interface Descriptor:
bAlternateSetting 0
Endpoint Descriptor:
wMaxPacketSize 0x0000 1x 0 bytes
Endpoint Descriptor:
wMaxPacketSize 0x0000 1x 0 bytes
Interface Descriptor:
bAlternateSetting 1
Endpoint Descriptor:
wMaxPacketSize 0x0009 1x 9 bytes
Endpoint Descriptor:
wMaxPacketSize 0x0009 1x 9 bytes
Interface Descriptor:
bAlternateSetting 2
Endpoint Descriptor:
wMaxPacketSize 0x0011 1x 17 bytes
Endpoint Descriptor:
wMaxPacketSize 0x0011 1x 17 bytes
Interface Descriptor:
bAlternateSetting 3
Endpoint Descriptor:
wMaxPacketSize 0x0019 1x 25 bytes
Endpoint Descriptor:
wMaxPacketSize 0x0019 1x 25 bytes
Interface Descriptor:
bAlternateSetting 4
Endpoint Descriptor:
wMaxPacketSize 0x0021 1x 33 bytes
Endpoint Descriptor:
wMaxPacketSize 0x0021 1x 33 bytes
Interface Descriptor:
bAlternateSetting 5
Endpoint Descriptor:
wMaxPacketSize 0x0031 1x 49 bytes
Endpoint Descriptor:
wMaxPacketSize 0x0031 1x 49 bytes
It does seem like it is the same problem -- I just removed --enable-msbc and now when I record I'm able to hear using sco the playback is choppy but it works.
It's something different, as that kernel should not be trying to use alt mode 6. Though it is probably related to how the eSCO channel is used. Could be MTU related. What chip does the adapter use?
CSR may require an 5.9 kernel, https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/bluetooth/btusb.c?h=linux-5.9.y&id=cde1a8a992875a7479c4321b2a4a190c2e92ec2a
This one seems important for many USB BTs:
https://patchwork.kernel.org/project/bluetooth/patch/[email protected]/
The latter is my patch to fix this, which doesn't seem to be taken up yet.
However, I think @jemershaw has a different problem.
- Kernel 5.4 should use alt 1, which works. It is kernel 5.8+ that is broken.
- The kernel 5.8+ bug should spam URB submission failures. It will use alt 0, which has a 0 byte max size, so every packet will be too big to send.
- CSR8510 should work. My "Sabrent" branded CSR8510 does.
- The apparent proper MTU is 24, and that is what current blue-alsa uses.
So it's something else. It could be related to the patch for kernel 5.9 for fake CSR8510 chips. Tracing both the bluetooth with btmon and usb with wireshark might help.
@xyzzy42 , I saw you discussing adding proper MTU support for ALT 1 vs. ALT 6 too. Do you have anything you can post ? Seems to be the last missing piece for USB BT mSBC on odd adapters.
I've yet to find a BT adapter that supports ALT 6. So what bluez-alsa does now by assuming 24 byte MTU should work most of the time. Someone else had created a patch, referenced in this thread earlier, to add the support needed for getting both alt1 and alt6 MTU detectable by bluez-alsa. But my understanding was that it had a flaw, where the alt mode choice was made, and the author has yet to rework it to fix that. So I don't think that has been re-submitted for 5.11 at this point. But unless you happen to have one of the alt 6 USB BT adapters, this isn't necessary.
But an app should not need know this and be able to trust MTU given by the kernel. Not all BT adapters are USB too
It doesn't seem to matter for UART based BT adapters, as they don't have to packetize the data over the UART link. I don't know about SDIO adapters, never seen one used.
Certainly the MTU should be reported correctly. But it appears the current behavior of bluez-alsa will almost always work once the bug in kernel 5.8+ is fixed.
There seems to be quite a few USB controllers gaining the BTUSB_WIDEBAND_SPEECH which I guess means HW mSBC but currently there is no way to select this mode. Any idea if one could patch the kernel to default to HW mSBC and user apps like bluealsa/pulseaudio would just use it automatically?
I've never seen documentation that explains the slightest bit about how one might get hardware mSBC on USB. The chip makers keep their firmware docs secret. Even when I worked on devices that had a Wifi/BT chip, we never got any documentation.
Seems like you ALT 1 patch has been accepted now, I don't see any stable keywords there so not sure it will make it to 5.10.x ?
No, it's not queued for 5.8 - 5.10 stable. Do you know of any bugs, besides this one I reported, about this? I could forward to stable but it would be better if there was already a Fedora/Debian/Ubuntu/Arch etc. bug report that this fixes.
I don't know of any other report. Best to forward to stable so all get this fix.
@xyzzy42 As this patches fixes a regression, it should be marked as such and backported to stable trees.
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/572 https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/568
@xyzzy42 The patch will be in 5.12 and has been backported to Linux 5.10.18 and 5.11.1 https://lore.kernel.org/lkml/[email protected]/ https://lore.kernel.org/lkml/[email protected]/
Trent Piepho (1): Bluetooth: btusb: Always fallback to alt 1 for WBS
Just a FYI:
- I'm running Ubuntu 20.04 on a Toshiba laptop, Intel bluetooth
- Running hwe kernel -> 5.8.0 kernel
- Bought recently headphones with HFP/A2DP sinks
- HFP did not work
- Arrived here following the "Device does not support ALT setting 6" message
- After reading some comments, and having installed default Ubuntu kernel, I tried 5.4.0-72 package ... output very noise, mic not working, unstable behavior.
- After reading final comment, installed mainline kernel, 5.10.32 -> it works like a charm
Thanks!
bluetooth-next seems to have merged a patch that switches it to ALT 3, https://lore.kernel.org/linux-bluetooth/[email protected]/T/#mc65bdf1658e19e511bb28dc604e21643eec5e054 This seems to break things... In principle one could now do
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index a9855a2dd561..c73d372a9159 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -1763,9 +1763,11 @@ static void btusb_work(struct work_struct *work)
/* Because mSBC frames do not need to be aligned to the
* SCO packet boundary. If support the Alt 3, use the
* Alt 3 for HCI payload >= 60 Bytes let air packet
- * data satisfy 60 bytes.
+ * data satisfy 60 bytes. USB Alt 3 support also needs
+ * HFP transparent MTU >= 72 Bytes.
*/
- if (new_alts == 1 && btusb_find_altsetting(data, 3))
+ if (new_alts == 1 && btusb_find_altsetting(data, 3) &&
+ hdev->sco_mtu >= 72)
new_alts = 3;
}
to at least make sure the MTU is not smaller than the "packet size", but I suspect ALT3 should be behind a quirk, as it seems at least Intel 8087:07dc which has large enough mtu produces garbled audio output (but hard to be sure since the device has problems with pairing w/ current kernels/firmware, and also ALT1 no longer works on current kernels)...
I use pipewire and have intel 8087:0a2b, and the patch above fixed the garbled audio issue when using msbc with kernel >=5.13.3. Thanks!
I've got access to a wideband BT+USB HCI sniffer for a bit and revisited this. The RTL8167B is the one adapter I have that didn't work.
It is being set to alt mode 3, 25 byte max packet size. Bluealsa is using: D: hci.c:141: USB adjusted SCO MTU: 28: 24.
Each audio packet is sent on 2 USB frames. The first frame contains:
Connection Handle 02 00
- Length
18 - Data (22 bytes)
The 2nd frame is:
- Data (2 bytes)
Probably not ideal here to be splitting the 24 bytes across two frames. The data is valid mSBC, which can be extracted from the USB HCI capture and sounds fine. As does the incoming audio also present in the USB capture. I didn't tell bluealsa to record, but the audio comes in anyway.
The bluetooth side is not correct. In the central/master to peripheral/slave slot, there is just a POLL packet. No data. In the following slot (peripheral -> center), there is a 2-EV3 packet with 60 bytes of data payload (65 bytes total size with header + CRC). These packets contain a valid incoming mSBC audio stream.
So for whatever reason the BT adapter has decided it's just not going to send the audio out on the air at all. Maybe it doesn't like how it's split across two USB frames. Or maybe there is some command to tell it to get audio from USB rather than an I2S PCM interface.
D: hci.c:141: USB adjusted SCO MTU: 28: 24
Bluealsa currently uses a fixed packet size of 24 bytes for all mSBC over USB - perhaps that is causing the issue with your Alt-3 device. I suspect it needs to set the packet size to 60 bytes. I've recently raised a PR that tries to address this, see PR #550. I am unable to test this with Alt-3, so if you are able to try it and report the result that would be fantastic!
I think it needs to use Alt 1. I've tested on Windows, and it seems to work. It's using alt 1. The output over USB is 3 packets of 9 bytes, one per ms. Total 27 bytes - 3 header = 24 data. Like expected. This produces an outgoing/incoming pair of 2-EV3 packets like it should.
USB HCI traffic contains one out and then one in packet per frame. Each 9 bytes. The start of the HCI packet isn't aligned between in and out on the same frame. One frame will have the 1st third of the out packet and the 2nd third of the in packet, the next frame the 2nd out and 3rd in, and so on. So the input and output packets don't need to be exactly aligned.
The 2-EV3 packet has 60 data bytes, sent every 7.5 ms, while USB is 24 bytes every 3 ms, which averages out to the same rate.
The bluetooth packets seem to be roughly aligned to the USB SOF, every 12 bluetooth slots or 7.5 USB frames. The timing of packets looks somewhat like this. Each letter = 12 bytes.
000 ms: USB HCI start 001 ms: USB data 003 ms: USB HCI end: data [z | A] 004 ms: USB HCI start 005 ms: USB data 006 ms: USB HCI end: data [B | C] 007 ms: USB HCI start 008 ms: USB data 009 ms: USB HCI end: data [D | E] 010 ms: USB HCI start 011 ms: USB data 012 ms: Bluetooth packet: data [ABCDE] 012 ms: USB HCI end: data [a | b]
It looks like as soon as it has received 60 bytes of data, it will send the BT packet in the next SCO scheduled transmission, which happens about 62 μs before the USB SOF when they are aligned.
The USB interface alternate setting selection for SCO is made by the kernel btusb module, and there is no API that allows userspace to influence this.
If the driver is selelecting the "wrong" Alternate Setting (ie selecting Alt-3, when this device needs Alt-1) then that is an issue for the kernel btusb developers; I think there is nothing BlueALSA can do about it.
However, if the RTL8167B is capable of handling SCO streams with Alt-3, then btusb is correct, and BlueALSA needs to modify its write() chunk size in order to achieve the required data rate. It is this case that PR #550 is trying to address.
Since you have confirmed that the Windows driver selects Alt-1, it seems most likely that the problem here lies with btusb.
Here's the kernel code snippet from drivers/bluetooth/btusb.c that sets the Alt-3 flag for your device:
if (IS_ENABLED(CONFIG_BT_HCIBTUSB_RTL) &&
(id->driver_info & BTUSB_REALTEK)) {
hdev->setup = btrtl_setup_realtek;
hdev->shutdown = btrtl_shutdown_realtek;
hdev->cmd_timeout = btusb_rtl_cmd_timeout;
/* Realtek devices need to set remote wakeup on auto-suspend */
set_bit(BTUSB_WAKEUP_AUTOSUSPEND, &data->flags);
set_bit(BTUSB_USE_ALT3_FOR_WBS, &data->flags);
}
... and here's the snippet that selects Alt-3 based on that flag:
if (btusb_find_altsetting(data, 3) &&
hdev->sco_mtu >= 72 &&
test_bit(BTUSB_USE_ALT3_FOR_WBS, &data->flags))
new_alts = 3;
So the kernel selects Alt-3 if, and only if, all the following 4 conditions are true:
- the kernel is compiled with CONFIG_BT_HCIBTUSB_RTL
- the adapter identifies itself as a Realtek bluetooth USB device
- the adapter supports AlternateSetting 3
- the adapter SCO buffer size is greater than or equal to 72
I tried alt 1 way back here https://github.com/Arkq/bluez-alsa/issues/400#issuecomment-738651403 and it produced broken audio. It's strange the Realtek are the ones who changed the driver to use alt3 instead of alt1, and yet their windows driver uses alt1.
OK, so if Alt-1 does not work with the Realtek Linux driver, then I think comparisons with the Windows driver are not valid. Perhaps Realtek supply different firmwares for Windows and Linux?
It seems we need to use Alt-3, and therefore BlueALSA needs to be modified. If you could obtain the payload size of the incoming SCO HCI packets (either by montoring the HCI data or by adding a debug statement to BluelALSA src/sco.c reporting the size read by the decoder thread), then that is the size the BlueALSA needs to write. PR #550 tries to do this, but needs testing with a greater range of adapters to verify that the logic is correct in all cases. My understanding is that Alt-3 is capable of holding 72 bytes, but SCO only uses 60 bytes, thereby wasting some USB bandwidth. However, I have found no documentation that verifies this, nor do I have access to any device that uses Alt-3 to test it.
... on the subject of firmware, I can't see a file in /lib/firmware/rtl_bt/ that matches rtl8167b. In fact, I can't see any reference to "8167" in the btrtl driver code. Please can you confirm which firmware (if any) is loaded by the Linux driver?
FWIW, ALT3 mSBC works fine on RTL 8671B/BU (0bda:8771), and appears to work better on ALT3 than ALT1. It would be the job of the kernel driver to set the BTUSB_USE_ALT3_FOR_WBS quirk properly for each device, if it only works on some of them. Maybe the RTL people did not test their patch with all their devices (it obviously wasn't tested with devices from other manufacturers).
I got the FW from a driver at mpow_MPBH456AB_driver+for+Linux.tgz, which looks like it is no longer available. There is RTL8761B firmware in linux-firmware now, there wasn't before, but it's different than the version I have. The version I tested identified as 0x0999646b, while linux-firmware has 0x09a98a6b, apparently newer.
I get a lot of hci0: command 0x0405 tx timeout errors with the new firmware I didn't get before. Using Alt3 + MTU 24 is no better. Plus a bonus kernel crash when removing the device!
hci0: command 0x0405 tx timeout
command 0x0405 is HCI_OP_CREATE_CONN and is sent to establish an ACL connection - this I think is a different issue to SCO MTU errors and USB isochronous endpoint settings.
@xyzzy42 I believe that with Alt-3, bluealsa needs to write SCO in chunks of 60 bytes, or possibly 72 bytes (it should be the same as the read() size of incoming SCO). If you could test that it be very informative.
ALT3 mSBC works fine on RTL 8671B/BU (0bda:8771)
@pv is that with bluealsa writing chunks of 24 bytes? If so that is surprising to me - what is the read() size for incoming SCO?
It's pipewire. Write/read size is 72, anything else produces no output.
On April 1, 2022 7:15:13 PM UTC, borine @.***> wrote:
hci0: command 0x0405 tx timeoutcommand 0x0405 is HCI_OP_CREATE_CONN and is sent to establish an ACL connection - this I think is a different issue to SCO MTU errors and USB isochronous endpoint settings.
@.*** I believe that with Alt-3, bluealsa needs to write SCO in chunks of 60 bytes, or possibly 72 bytes (it should be the same as the read() size of incoming SCO). If you could test that it be very informative.
ALT3 mSBC works fine on RTL 8671B/BU (0bda:8771)
@.*** is that with bluealsa writing chunks of 24 bytes? If so that is surprising to me - what is the read() size for incoming SCO?
Not having much luck with the newer? firmware. Constant timeouts, crashes, etc. It's hung the USB port it was on, nothing is detected on that port anymore, even random other devices. Probably recoverable by unbinding and binding the affected xhci device from the driver.
Tried MTU of 60, with old firmware, no luck:
kernel: Bluetooth: hci0: urb 00000000330954a3 submission failed (90)
kernel: Bluetooth: hci0: sending frame failed (-90)
kernel: Bluetooth: hci0: urb 00000000330954a3 submission failed (90)
kernel: Bluetooth: hci0: sending frame failed (-90)
With a MTU of 72, it works. There is always a glitch when the stream starts, which is combined with a -90 error (EMSGSIZE).
I haven't traced this yet. It's not clear to me how a MTU of 72 is supposed to work. The eSCO BT stream should be one 60 bytes of payload 2-EV3 packet every 7.5 ms. The 24 bytes per 3 ms of Alt 1 matches this rate exactly, with 5 USB HCI packets per 15 ms split into exactly 2 BT 2-EV3 packets per 15 ms. 72 bytes per 3 ms is obviously too fast. Does it just leave the 3 or 4 iso spots unused in usb frames after the first three?
@pv Many thanks for that info. So now we know 72 bytes is correct for Alt-3. PR #550 will therefore work correctly with Alt-3.
@xyzzy42 Please can you try PR #550 - that will use 72 bytes; I would like to know if the EMSGSIZE error still occurs then.
I hope that next week I'll have time to read through the btusb code again to understand how it converts 72 byte socket messages to USB Alt-3 packets with correct timing.
Here is a dump of the USB and BT traffic combined for the first 75ms. Trying to export the data from the Ellisys capture program in a parseable format has been a nightmare.
Only the user payload data is shown in USB HCI packets as the header was removed. But in the BT packets it's not removed, so the first three bytes are header and the last two are CRC, the rest match the HCI payloads. Timestamp of an HCI packet is of the start of the last of the three individual USB ISO packets it was transmitted on, one per millisecond. BT timestamp is the start of the packet. A 2-EV3 is just one slot, unlike a 2-DH3 which is three slots. It won't export the direction of the eSCO packets, but the first of a pair is out and the one following it is in.
I imagine the glitch is the 15 ms gap in output HCI packets between 0.011 and 0.026.
-0.033742183; HCI Synchronous Connection Complete (Success, Connection=0x0002, 2C:41:A1:03:4A:DF, eSCO, Interval=7.5 ms, Retransmission=2.5 ms, Rx=60, Tx=60, Mode=Transparent);
-0.003735583; HCI SCO Data OUT ; BB 02 C3 41 3C EF 2D AF D4 34 13 ED F2 BB 04 83 41 3C BF 2B AF C8 34 13 EB F2 BA FC 83 41 3D 0F 2B AF C8 00 01 F8 AD 00 00 1C AA 00 00 01 0D 24 FA BC B6 BF 10 D0 4F 43 CA EB F9 0D 04 FC 3C B6 C1 30 D0 4F AF CA EB F3;
0.000000000; 2-EV3 packet (eSCO, 2 Mbps) ; B2 70 02 BB 02 C3 41 3C EF 2D AF D4 34 13 ED F2 BB 04 83 41 3C BF 2B AF C8 34 13 EB F2 BA FC 83 41 3D 0F 2B AF C8 00 01 F8 AD 00 00 1C AA 00 00 01 0D 24 FA BC B6 BF 10 D0 4F 43 CA EB F9 0D 88 17;
0.000626125; NULL packet (eSCO) ; 82 89 02;
0.003264033; HCI SCO Data OUT ; 0D 04 F2 BC B6 BF 20 D0 4F B7 CA EC 0B 0D 04 FE 7C AE BF 00 D0 4F B8 00 01 08 AD 00 00 1C AA 00 00 01 F2 BB 04 03 41 3C CF 2B B0 48 34 13 D7 F2 BA FB C3 41 3C 6F 2B B0 2C 34 93 F9 F2 DB 04 C3 41 3C FF 2B AF BC 34 93;
0.007499500; 2-EV3 packet (eSCO, 2 Mbps) ; B2 E6 01 04 FC 3C B6 C1 30 D0 4F AF CA EB F3 0D 04 F2 BC B6 BF 20 D0 4F B7 CA EC 0B 0D 04 FE 7C AE BF 00 D0 4F B8 00 01 08 AD 00 00 1C AA 00 00 01 F2 BB 04 03 41 3C CF 2B B0 48 34 13 D7 F2 44 C4;
0.008125625; 2-EV3 packet (eSCO, 2 Mbps) ; B2 BB 03 01 C8 AD 00 00 C5 00 00 00 00 77 6D B6 DD DB 6D B7 76 DB 6D DD B6 DB 77 6D B6 DD DB 6D B7 76 DB 6D DD B6 DB 77 6D B6 DD DB 6D B7 76 DB 6D DD B6 DB 77 6D B6 DD DB 6D B7 76 DB 6C 00 90 D0;
0.009257233; HCI SCO Data IN ; 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00;
0.010257317; HCI SCO Data IN ;
0.011280917; HCI SCO Data OUT ; CF F2 BA FC 03 41 3E DF 2B AF C4 00 01 38 AD 00 00 19 AA 10 00 00 0D 04 F4 3C AE C0 F0 D2 4F DB CA EC 0B 0D 04 F4 3C AE C0 70 D0 4F 47 CA EC 14 0D 04 F3 BC AE C0 90 D0 4F C7 CA EC 12 0D 04 F3 7C AE C0 E0 D0 4F 40 00;
0.014999375; 2-EV3 packet (eSCO, 2 Mbps) ; B2 70 02 BA FB C3 41 3C 6F 2B B0 2C 34 93 F9 F2 DB 04 C3 41 3C FF 2B AF BC 34 93 CF F2 BA FC 03 41 3E DF 2B AF C4 00 01 38 AD 00 00 19 AA 10 00 00 0D 04 F4 3C AE C0 F0 D2 4F DB CA EC 0B 0D 76 17;
0.015626625; 2-EV3 packet (eSCO, 2 Mbps) ; B2 2D 00 01 F8 AD 00 00 CA 74 32 11 05 7E F6 D5 DF BD B5 77 AD 6D 5D EC 14 57 56 10 69 D6 E9 A9 8B 6B 6D 67 44 5B 59 B4 D6 D6 A0 C1 B5 B5 72 6D 6D 12 1B 5C 51 66 D7 1A B9 B5 C9 AA 6D 74 00 DE 37;
0.018257117; HCI SCO Data IN ; 0D F9 B4 E1 F7 DE EC EF 35 DC B2 5E B1 C7 65 61 BD EF 21 52 6E 8C 02 00 48 A8 33 CC ED 45 62 91 36 02 A5 9D 75 00 81 5C C7 A4 4A F7 BA C3 08 FA 78 A4 2A F4 E5 43 66 92 3B 63 88 6C 05 00 25 CF F1;
0.022499500; 2-EV3 packet (eSCO, 2 Mbps) ; B2 E6 01 04 F4 3C AE C0 70 D0 4F 47 CA EC 14 0D 04 F3 BC AE C0 90 D0 4F C7 CA EC 12 0D 04 F3 7C AE C0 E0 D0 4F 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CF 31;
0.023126500; 2-EV3 packet (eSCO, 2 Mbps) ; B2 BB 03 01 08 AD 00 00 89 DB BB 9A 9A 7D DD AD 5F 77 6B 57 5A 1A D5 DB 57 31 28 33 40 A2 3D 43 9A 1D DA D6 66 86 B5 86 1D AD 5D 77 6B 56 DD DA D5 C7 76 B5 75 DD AD 5F 77 6B 58 1D DA D4 00 9D 72;
0.026280583; HCI SCO Data OUT ; 01 C8 AD 00 00 50 AA 00 01 01 F2 B5 EC C3 42 7B CF 2B 5F 0C 34 27 C5 F2 B5 E6 83 42 7A AF 2B 5F 08 34 27 BC F2 B5 EF 03 42 7B BF 2B 5E CC 34 27 BA F2 B5 EA C3 42 79 AF 2B 5F 04 00 01 F8 AD 00 00 01 AA 00 00 00 0D 18;
0.030000000; 2-EV3 packet (eSCO, 2 Mbps) ; B2 70 02 01 C8 AD 00 00 50 AA 00 01 01 F2 B5 EC C3 42 7B CF 2B 5F 0C 34 27 C5 F2 B5 E6 83 42 7A AF 2B 5F 08 34 27 BC F2 B5 EF 03 42 7B BF 2B 5E CC 34 27 BA F2 B5 EA C3 42 79 AF 2B 5F 04 00 39 76;
0.030627125; 2-EV3 packet (eSCO, 2 Mbps) ; B2 2D 00 01 38 AD 00 00 A3 C9 9A 89 88 8A DB B6 E2 36 ED B8 2D BB 6D ED 4D 59 64 75 B2 77 8C C5 DA 0D BB 6D 0A 6E DB 24 DB B6 D1 B6 ED B7 ED BB 6E A3 6E DB B8 DB B6 EB B6 ED B9 4D BB 6C 00 96 91;
0.033280883; HCI SCO Data OUT ; 9E FC B3 D8 20 D2 09 F3 CB 4D 82 0D 18 9E FC B2 D8 30 D2 49 F3 CB 2D 83 0D 08 9F 3C B3 D8 30 D1 C9 EF CB 3D 83 0D 1C 9E FC B3 D8 20 D1 C9 EC 00 01 08 AD 00 00 CC AA 00 00 10 F2 BB 05 03 49 3D 2F 2B B0 3C 34 13 CD F2;
0.037500250; 2-EV3 packet (eSCO, 2 Mbps) ; B2 E6 01 01 F8 AD 00 00 01 AA 00 00 00 0D 18 9E FC B3 D8 20 D2 09 F3 CB 4D 82 0D 18 9E FC B2 D8 30 D2 49 F3 CB 2D 83 0D 08 9F 3C B3 D8 30 D1 C9 EF CB 3D 83 0D 1C 9E FC B3 D8 20 D1 C9 EC 00 03 97;
0.041263667; HCI SCO Data OUT ; BB 04 43 49 3C EF 2B AF C8 34 93 D7 F2 BB 04 43 41 3D 2F 2B B0 3C 34 93 D3 F2 BB 03 03 49 3C EF 2B B0 4C 00 01 38 AD 00 00 B5 AA 00 10 00 0D 24 F3 7C AE C0 C0 D0 4F 2B CA EC 0B 0D 04 F1 FC AE C1 40 D2 4F 37 CA EC 0E;
0.044999750; 2-EV3 packet (eSCO, 2 Mbps) ; B2 70 02 01 08 AD 00 00 CC AA 00 00 10 F2 BB 05 03 49 3D 2F 2B B0 3C 34 13 CD F2 BB 04 43 49 3C EF 2B AF C8 34 93 D7 F2 BB 04 43 41 3D 2F 2B B0 3C 34 93 D3 F2 BB 03 03 49 3C EF 2B B0 4C 00 73 67;
0.045626625; 2-EV3 packet (eSCO, 2 Mbps) ; B2 2D 00 01 F8 AD 00 00 6E EA 99 87 56 DF 78 D8 A4 A2 AC D0 35 23 B4 46 2E ED 3A 22 BB 69 AC CE DF 86 B3 37 AA 6C ED CA 83 C3 64 9A EC D5 97 BB B4 E9 EE ED 36 7C 33 52 DE EE D6 D7 BB B4 00 45 22;
0.048256617; HCI SCO Data IN ; 99 F5 40 7B AC 5E 14 0E 79 76 22 DD 6C 4A 8A 09 B8 BD D2 2A FF 97 02 00 48 79 3A D1 BB 56 00 DE A5 F2 61 F7 6B 42 EB F6 DF B2 02 0F 6E 01 62 EF 9F 08 9F C0 D1 85 82 D0 59 8B 05 EE D7 09 C8 B9 FF B1 A8 7E C7 68 80 90 6B D4 0A AF E8 8B 14 6E DF C3 51 65 D9 9D 95 D8 4A A2 C3 35 FD B0 37 F2 B5 02 00 48 2B 0D B4 FB 23 57 F6 FD 20 0B B0 5A 00 7C FA 8D 6B D9 E5 C1 15 26 80 5E B8 69 7F B5 0E 6C DB 64 14 41 78 FE 0D F1 B3 67 54 EC F9 B3 18 A9 B9 B9 3F 16 98 FF 84 31 7A D8 01 63 E7 3D 8C A1 FE 53 A4 0F ED 74 8E B2 A7 C3 02 00 48 A6 A0 E3 64 8D 39 6F CF 54 50 FB 55 F9 33 D5 79 A4 8F 06 BE 3B CE 54 9E 67 BC 03 A6 0E C5 42;
0.048280283; HCI SCO Data OUT ; 0D 04 F5 3C AE C0 D0 D2 4F 4B CA EC 0B 0D 24 F3 7C AE C1 30 D2 4F 44 00 01 C8 AD 00 00 CC AA 00 00 10 F2 BB 05 03 49 3C BF 29 B0 44 34 13 CA F2 BB 03 C3 41 3C AF 2B B0 44 34 13 CA F2 BB 06 03 49 3C FF 2B B0 2C 34 93;
0.052499750; 2-EV3 packet (eSCO, 2 Mbps) ; B2 E6 01 01 38 AD 00 00 B5 AA 00 10 00 0D 24 F3 7C AE C0 C0 D0 4F 2B CA EC 0B 0D 04 F1 FC AE C1 40 D2 4F 37 CA EC 0E 0D 04 F5 3C AE C0 D0 D2 4F 4B CA EC 0B 0D 24 F3 7C AE C1 30 D2 4F 44 00 8C A7;
0.053126625; 2-EV3 packet (eSCO, 2 Mbps) ; B2 BB 03 01 08 AD 00 00 4B EE CA 99 A9 84 F7 6A E6 BD DA BA 6F 76 AE CC 19 2B 8C C8 8A CF C2 1A B5 4E 66 AD DB DD AB BF 07 6A E2 AD E4 CA 18 3C 47 CB 55 32 73 06 8A C1 3D 9A B1 0F 76 AC 00 73 C7;
0.056256583; HCI SCO Data IN ; 96 52 D1 0F DF 26 DE 66 77 7C 3E 1A 28 53 5B 0A 2F E6 29 46 AB 7A 02 00 48 83 16 79 BF BA 52 BB 7F 22 7C 55 AF 4C BA 5F 9C A2 00 35 D6 34 49 39 76 A1 87 B0 CF 90 41 05 D7 AF 89 FF AF A3 F9 A6 27 E5 02 E9 C2 35 01 EE 20 A0 CD 55 E8 9A 09 A9 BE 8B 1C F9;
0.056280333; HCI SCO Data OUT ; CD F2 BB 04 83 49 3D 1F 2B B0 38 00 01 F8 AD 00 00 D1 AA 00 00 11 0D 09 EA FC AD 7A 40 D0 9E 93 CA D7 B2 0D 09 F1 7C AD 79 30 D0 9F 0B CA D7 E2 0D 09 EC FC AD 7C 30 D0 9E EB C9 D7 BC 0D 09 F3 3C AD 7B B0 D0 9E CC 00;
0.060000250; 2-EV3 packet (eSCO, 2 Mbps) ; B2 70 02 01 C8 AD 00 00 CC AA 00 00 10 F2 BB 05 03 49 3C BF 29 B0 44 34 13 CA F2 BB 03 C3 41 3C AF 2B B0 44 34 13 CA F2 BB 06 03 49 3C FF 2B B0 2C 34 93 CD F2 BB 04 83 49 3D 1F 2B B0 38 00 66 58;
0.060627125; 2-EV3 packet (eSCO, 2 Mbps) ; B2 2D 00 01 38 AD 00 00 82 EB A8 86 77 31 56 6C 23 25 5B 1E 34 66 E7 8A DC 25 7E 2E A6 59 12 63 19 57 76 D6 A8 D8 B5 A0 B5 6D 5A 99 9B 53 67 66 D4 89 DD B5 30 77 6D 57 9D DB 59 97 76 D4 00 61 B5;
0.062256467; HCI SCO Data IN ; EC 10 7E 9F BC 10 F7 FF F4 7E 1C 61 60 8F 1C 0B C4 CC D5 13 F5 5A;
0.067500375; 2-EV3 packet (eSCO, 2 Mbps) ; B2 E6 01 01 F8 AD 00 00 D1 AA 00 00 11 0D 09 EA FC AD 7A 40 D0 9E 93 CA D7 B2 0D 09 F1 7C AD 79 30 D0 9F 0B CA D7 E2 0D 09 EC FC AD 7C 30 D0 9E EB C9 D7 BC 0D 09 F3 3C AD 7B B0 D0 9E CC 00 B7 02;
0.068127125; 2-EV3 packet (eSCO, 2 Mbps) ; B2 BB 03 01 C8 AD 00 00 E1 E8 65 54 53 C3 BD D5 73 2F 75 5B 9B DD 56 64 F7 55 78 BD 95 58 8F 75 55 A3 DD 55 7A D6 55 6B 41 25 5D C5 06 98 75 1C 92 60 C2 59 97 BD 14 A2 CE 79 17 D3 E5 54 00 5D 40;
0.071256267; HCI SCO Data IN ; A8 D0 2F 6B DD 4C 78 E6 AE 1B 7A 39 5B 57 39 A7 02 B7 EA 7C BB 6A 37 5C F9 C8 17 F1 DF CE 17 F8 3B 0F 01 C6 CD 20 92 32 3C 73 00 73 99 83 1C 02 00 48 D6 9C 8C 38 4F 5A 03 34 E7 51 47 46 E8 3F 1A 67 7B E6 04 26 76 F9 39 02 8A 97 1A 05 36 56 11 30 CE 67 29 43 7E AF 2D 84 EF FA 75 59 1B DD 98 84 BF B8 AA 82;
0.071280017; HCI SCO Data OUT ; 01 08 AD 00 00 CC AA 00 00 10 F2 BB 03 43 49 3C EF 29 B0 40 34 13 D0 F2 BB 03 83 49 3D 2F 29 B0 44 34 93 D0 F2 BB 03 C3 49 3C 5F 29 B0 50 34 93 CD F2 BB 03 43 49 3D 1F 2B B0 48 00 01 38 AD 00 00 01 AA 00 00 00 0D 3C;
0.074999875; 2-EV3 packet (eSCO, 2 Mbps) ; B2 70 02 01 08 AD 00 00 CC AA 00 00 10 F2 BB 03 43 49 3C EF 29 B0 40 34 13 D0 F2 BB 03 83 49 3D 2F 29 B0 44 34 93 D0 F2 BB 03 C3 49 3C 5F 29 B0 50 34 93 CD F2 BB 03 43 49 3D 1F 2B B0 48 00 EE CE;
0.075626625; 2-EV3 packet (eSCO, 2 Mbps) ; B2 2D 00 01 F8 AD 00 00 8F B7 87 76 75 1E DA 36 C5 C7 6D 34 0D DB 6D EB 76 DB A4 E1 B6 ED 26 6D 4A 4D D3 6E 32 98 DB 86 C0 02 94 97 A4 B7 CA 9D 1A 43 78 E3 84 9D B6 9B 48 52 36 2D DC 70 00 5E 0C;
0.077256283; HCI SCO Data IN ; 45 27 00 28 6E 69 B0 C8 B5 77 6D 66 DF 6C DE 32 B2 EE C2 84 92 7B;
Further analysis of the output timing. The USB cadence appears to be {7, 8, 7, 8, 15} milliseconds between packets of 72 bytes. The average rate of the five packets is 360 bytes in 45 ms. The BT cadence is {7.5, 7.5, 7.5, 7.5, 7.5, 7.5} with 60 byte packets. So also 360 bytes in 45 ms. The order then looks like [U B U B U B U B U B B].
It's not clear why this should be better than Alt 1, since it's still splitting HCI packets. It just wastes iso slots by not using every usb frame to transmit data.
I think the glitch might be because the initial three USB packets have sent 27 ms of audio, yet only 22 ms have elapsed. There might not be enough audio ready in time to send the fourth packet when it's supposed to go out.