search

arkq / bluez-alsa

Bluetooth Audio ALSA Backend
MIT License
862 stars 189 forks source link

No sound with HFP with USB BCM20702A1 adapter #400

Closed xyzzy42 closed 1 year ago

xyzzy42 commented 3 years ago

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.

borine commented 2 years ago

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!

xyzzy42 commented 2 years ago

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.

borine commented 2 years ago

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:

xyzzy42 commented 2 years ago

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.

borine commented 2 years ago

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.

borine commented 2 years ago

... 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?

pv commented 2 years ago

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).

xyzzy42 commented 2 years ago

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!

borine commented 2 years ago

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?

pv commented 2 years ago

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 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.

@.*** 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?

xyzzy42 commented 2 years ago

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?

borine commented 2 years ago

@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.

xyzzy42 commented 2 years ago

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;
xyzzy42 commented 2 years ago

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.

borine commented 1 year ago

Replaced by issue #622