No sound with HFP with USB BCM20702A1 adapter #400
Comments
|
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 |
|
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. |
Yes, that requirement for USB was introduced in Linux 5.8 - see #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 |
|
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). |
That would be the quirk flag 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: Correct object path you can find by issuing this: The list of available codecs query with: Reference: |
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.
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! |
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. |
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 |
|
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. 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. |
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 😃 |
|
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. |
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: 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? |
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 This is the output from bluealsa debug I also get this error code in the kernel. Please let me know if you need any information to debug further. |
|
What kernel version? Is the bluetooth adapter USB based? Run What's the highest AlternateSetting and MaxPacketSize it goes up to? |
|
Thanks for the help! I am running kernel version Here's the output for the AlternateSettings/MaxPacketSize. |
|
It does seem like it is the same problem -- I just removed |
|
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? |
|
bluetooth-next seems to have merged a patch that switches it to ALT 3, https://lore.kernel.org/linux-bluetooth/[email protected]/T/#mc65bdf1658e19e511bb28dc604e21643eec5e054 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:
The 2nd frame is:
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. |
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 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 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 However, if the RTL8167B is capable of handling SCO streams with Alt-3, then Since you have confirmed that the Windows driver selects Alt-1, it seems most likely that the problem here lies with Here's the kernel code snippet from ... and here's the snippet that selects Alt-3 based on that flag: So the kernel selects Alt-3 if, and only if, all the following 4 conditions are true:
|
|
I tried alt 1 way back here #400 (comment) 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 |
|
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 |
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.
@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 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?
… |
|
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: 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. I imagine the glitch is the 15 ms gap in output HCI packets between 0.011 and 0.026. |
|
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. |
|
Replaced by issue #622 |
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:
Once SCO playback is started, I get these messages from the kernel:
The last two messages then repeat constantly.
The text was updated successfully, but these errors were encountered: