How to add msbc codec to hfp profile #533
Comments
When mSBC is enabled, the sampling rate is not know prior to codec selection procedure. Codec selection might be performed just before first audio connection. So, in other words, you might see sampling rate as 0 Hz, which will change to 8000 or 16000 after first audio connection. In most cases codec selection is performed by the AG, so in case of Android HFP codec is selected before first audio transfer. When BlueALSA acts as an AG, codec selection is performed just after connection establishment, so PCM client will know sampling rate before starting audio. I know that this might be inconvenient for BlueALSA in HF mode, however, I'm not sure how to solve this issue. I might set codec to CVSD as a sane default, and it will be updated by the AG before audio transfer. However, this will most likely mean that prior to first audio transfer the PCM configuration will be incorrect (which right now is indicated by 0 Hz sampling rate). |
|
thanks for your suggestion, indeed it worked as soon as I opened and configured 2 PCMs for SCO. The displayed result of when i run the it shows the following error, that it's mSBC packets is missing. and I can't hear the sounds sent from my embedded device at all. Do you know where the cause lies? After a while, BlueALSA is completely stopped. |
Is |
|
Tks @borine for reply!!! Looks like things are getting worse. Right now the phonedown recording is no longer possible. I tried to try recording phonedown again with the following command for 16 kHz: after successful recording i tried to turn on after checking the PCM again I see it is still complete with the configuration for SCO as mSBC codec: strangely when I check with Also while running the whether my Bluealsa version has some error for mSBC decoding, i use bluealsa v3.1.0 and Bluetooth USB Modul BT850 of Cypress with CYW20704A2. In the datasheet I see that it also supports WBS (eSCO) over PCM, but I route my SCO Data through HCI via |
|
Hmm, looks like Linux has some problems with your BT adapter. The Linux USB bluetooth module ( |
|
Thank you very much. Maybe I can also figure out where the cause lies and may need to find a patch for |
|
There is an important change to UART should work fine, provided the serial device config is correct. Its been a long time since a last used mSBC with a UART adapter though. The SCO issues that I am aware of all relate specifically to USB. |
|
Is this problem really in Linux-Kernel? Actually, I also find it a bit ridiculous. I can totally record Phone Downlink but Phone Uplink is not working. This results in sound being transmitted from only one direction. But if the problem is really in the Linux-Kernel then it's possible that both ways won't work. What do you think could be the cause? |
You are absolutely correct there. Kernel 5.15 finally gets the USB Alt setting logic correct (I think, but I'm no expert), but it still fails to reliably inform the application of the correct packet size (MTU) for writing to a SCO socket. So applications such as bluealsa may not choose the correct value and therefore may fail to deliver data at the required rate. MTU for reading from the socket is not so critical, since the application can always read whatever data is available. I use mSBC successfully with 2 USB adapters, both quite old models, so I know it can work. There may be other underlying issues rather than I just did a quick search for CYW20704A2 and 04b4:f901 but found nothing that suggests issues with it. Do you know if anyone else is successfully using this adapter with Linux for mSBC? If it works with PulseAudio or Pipewire then it should work with BlueALSA |
|
After carefully studying the specs of CYW20704A2 and checking is there any other way i can make the frames less than 21 bytes in bluealsa without affecting the linux kernel? I get the following Debug when running the Looks like bluealsa configures SCO to be 21 bytes, but PCM returns 23 bytes. Is that the cause of the loss of SCO paket. One more assumption that leads me to only use arecord but not aplay, is the MTU configuration between Tx (aplay) and Rx (arecord) different? I think when an incoming packet arrives the daemon needs to read it as soon as possible - otherwise there is a risk the next packet will overwrite it in the controller's buffer and data is lost. because with mSBC SCO my chip only got 21 bytes MTU but Debug when a call is comming: Debug when i play the wav for PhoneUp |
No. those numbers (22 and 23) are the file descriptors of the SCO sockets, and have nothing to do with the number of bytes written. To understand the required size of each write() you need to know how USB isochronous endpoints work, and their relationship to the USB interface bAlternateSetting value. This is discussed in #400 (comment) - the socket layer code will add a USB header of 3 bytes, so you need to subtract 3 from the URB sizes calculated there to arrive at the MTU from the application's perspective. So in the end we arrive at: The problem for the application is that it does not know which Alternate setting is in use, and the socket reports wrong MTU values (e.g. in your case 64, which is wrong for any Alt setting). Bluealsa simply chooses to write 24 bytes in all cases, since this has proved to be a "safe" value that works in most cases (to date the majority of adapters seem to use Alt-1). Writing too many bytes can cause lockups in the system that require a hard reset, so it is not advisable to experiment with random values. |
|
Thank you very much for the suggestions. I will try patching |
|
Very helpful! I was really surprised when I changed Alt to 1. It work now for me to play PhoneUp with but with |
|
If the client ( This can happen when the client is writing to another device with its own clock, especially if that involves resampling to a different rate, because the resampler may introduce rounding error. However, if The latest bluealsa source uses a revised SCO design, so that may help. But if the problem is in the USB subsystem, then there is nothing that bluealsa can do.
|
|
thank you very much, up to this point can say Bluealsa works both ways quite well for mSBC. It's true that the buffer is a bit small, but since the audio signal is recorded directly to the file, it shouldn't have too much impact on the quality. is there any way to make bluealsa default setting sco_codec as msbc as soon as bluetooth device is connected. Because I sometimes have some problems like the following when making calls in HF mode: As @arkq explained, when there is an incoming call bluealsa will initiate the mSBC by itself but I make the call as soon as the device is connected bluealsa will hang in after a short time it will end completely: As far as I know, both Android phones and Iphones support mSBC, so the CVSD 8000 Hz configuration will not be needed and should always be configured for mSBC instead. Could the cause be that the SCO link has not been initialized? |
hmm, you may have found a bug here. it seems the socket is not fully configured at that point, so the call to getsockopt() is failing. As a result we have an MTU of 0. @arkq is the getsockopt() failure expected? before ac5706f the MTU would simply be set to 48, but since that commit it is left as 0. If the getsockopt() failure is normal, then a method of determining the MTU later is required; if the failure is not expected, maybe the message should be changed to error() and the transport code should abandon the link? |
|
I think that is should/shall not fail in any of the |
|
So, I now think this is probably not a bluealsa bug, at least not in the latest code. The debug logs given above appear to be from release 3.1.0. There has been a major re-design of SCO I/O in bluealsa since then, so before looking any deeper, we need to establish whether this behaviour persists in the latest code. I haven't been able to reproduce in simple tests, and I don't have time to set up a clean test system at the moment. @bmt1596 is it possible for you to build from the latest master branch and re-test? |
|
@borine no problem. i will try with the latest version of Bluealsa. Anyway, thank you very much for your help. |
|
@bmt1596, since you are experimenting with mSBC support, maybe you could try this PR #539 ? It adds PLC for received mSBC packets, so it should improve overall user experience when using mSBC codec. I've got no real test setup to check this PR properly, so I thought that maybe you could use this new code :). |
|
@arkq Hi, thank you very much for this help. I'm also having the problem of SBC packet loss for SCO but overall it doesn't affect too much. I try this new version with PLC support and update you with the results as soon as possible. |
Hi everybody. First I want to thank for bluealsa. Currently I am using Bluealsa to support device (HF) for A2DP-Sink and HFP and using phone (AG) to connect and transmit Sound and Voice to my embedded device.
My embedded device uses BlueZ version 5.46. Unexpectedly after installing Bluealsa on the device it seems to have worked quite well.
I installed for BlueALSA including the following options:
../configure --enable-debug --disable-payloadcheck --enable-cli --enable-rfcommIt works when I start bluealsa with the command:
bluealsa -i hci0 --syslog -p a2dp-sink -p hfp-hfp &The displayed result of
bluealsa-aplay-lis:So it can be said that BlueALSA has done its job well, but is there any other way to upgrade the sampling rate for voice channels? I have consulted in Bluealsa's issues and found that there are some cases where WBS is enabled via
--enable-msbcbut when I try it with my Linux Kernel version, it shows the following results:Looks like the sampling rate for SCO has not been configured. Do I need to upgrade the Linux-kernel version? and what is the minimum linux-kernel version for Bluealsa to update the mSBC-Codec. I am using petalinux 2018.3 and linux-kernel version is 4.14.0.
Hope to receive your reply as soon. Have a nice day!!
The text was updated successfully, but these errors were encountered: