FORUMS
Remove All Ads from XDA

BT Calling Robotic Audio

1,276 posts
Thanks Meter: 1,203
 
By ThePiGuy, Senior Member on 31st May 2018, 11:01 PM
Post Reply Email Thread
Hi Guys,

As you may notice from my signature, I'm actually an LG G4 owner (attempting ) to assist with the development of Oreo roms for the G4. @kessaras and @steadfasterX have done a magnificent job so far and we have two bugs left - the torch tile in quick settings doesn't work (not a big deal right now, we just recommend an app as a workaround) and also we have robotic bt calling with a hands free set.

I have been browsing the hammerhead forums and noticed that this exact problem is also plaguing the Nexus 5 (and we share the same broadcom 4339 bt/wifi chipset, so I would imagine this is why we suffer from the same issue), and I was wondering whether it would be a good idea to share any ideas here as to how we could fix it - we have tweaked a lot of bluetooth settings so far but it has either made no difference or killed the bluetooth entirely.

@amaces I noticed you mentioned in your Unlegacy Android thread that you got it to work in a hardcoded and messy way - would it be possible for you to share it? I know you said it wasn't good for a production build, but if we could see how you got it working then it would definitely help us to find a proper fix.

Thanks for any help
The Following 12 Users Say Thank You to ThePiGuy For This Useful Post: [ View ] Gift ThePiGuy Ad-Free
 
 
18th October 2018, 06:51 PM |#2  
Member
Thanks Meter: 1
 
More
I have that same problem. (android 8.1 or 9.0)
Nexus 5 D820
31st March 2019, 10:09 PM |#3  
Senior Member
Thanks Meter: 1,010
 
Donate to Me
More
The issue is probably caused by the HIDLization and the introduction of eSCO command set. Prior to Oreo vendor specific commands(VSCs) were sent to the controller which would trigger I2S/PCM sco configuration.
When the HIDLization started the VSC for the sco configuration was removed 796523d and later on with the introduction of eSCO command setup these calls to the broadcom's libbt-vendor(pre-SCO setup) were completely removed a9152a2.

I tried retrieving retrieving these calls removed by eSCO(3/5), yet I cant get it working.
Here's what I've done so far:
system/bt stack
fb1d404
47f50f8-a2df04b

hardware/interfaces
dd21c98

The issue is either the way I attempt to send the VSC via send_command method, or in some of the methods which are supposed to notify the AG that the pre-sco is done.
So far I noticed that the code of bta_ag_ci_sco_open_continue method is never reached, but things could've went south even before this method, I dunno.

Looking at the snoop log nothing is even sent to the controller about this.

@steadfasterX @ThePiGuy if you guys are still interested in fixing this issue, you should really focus on retrieving these calls imho.
The Following 25 Users Say Thank You to Sashko98 For This Useful Post: [ View ] Gift Sashko98 Ad-Free
1st June 2019, 05:26 PM |#4  
Senior Member
Thanks Meter: 1,010
 
Donate to Me
More
Would be good if anyone tries this c0d86fb. What I am trying is basically to avoid the need of hw_set_audio_state() call from bt stack to configurare SCO over PCM.
Should be accompanied by this commit in order to work.
@amaces @razorloves
The Following 19 Users Say Thank You to Sashko98 For This Useful Post: [ View ] Gift Sashko98 Ad-Free
18th June 2019, 12:48 AM |#5  
Junior Member
Flag Minsk
Thanks Meter: 403
 
More
Hi there,
Sorry for delay. I was a bit busy today. Here is my workaround for bt issue:
1) android_hardware_broadcom_libbt
2) device tree

Honestly this workaround is terrible (explanations will be provided below) and disabled by default. You should add two parameters to vendor config in order to activate it:
1) BTHW_FW_EXTENDED_CONFIGURATION - Enable/disable the fix. TRUE/FALSE. Default value is FALSE.
2) BTHW_FW_EXTENDED_SCO_CODEC - SCO codec. Use the numeric value from the sco_codec_t enum. Default value is SCO_CODEC_CVSD.

Seems that the problem lies in firmware for our BT chip and eSCO command set. Controller have invalid audio configuration or doesn't have any audio configuration at all after firmware upload. That was not a problem before this change (Thanks @Sashko98 for research). I've tried a solution proposed by @Sashko98 but nothing changed. After a couple of days playing with different parameters in configs i noticed interesting line in logcat:
Code:
W/bt_hci:
filter_incoming_event command complete event with no matching command (opcode: 0xfc6d)
0xfc6d is a HCI_VSC_WRITE_I2SPCM_INTERFACE_PARAM constant defined here and used inside of the hw_sco_i2spcm_config method. Seems that bt controller responds to HCI_VSC_WRITE_I2SPCM_INTERFACE_PARAM command. But why we still have an issue with audio? The answer is simple: SCO configuration can not be completed because bt_hci blocks events and callbacks are not called at all! If device uses SCO_INTERFACE_PCM bus interface then hw_sco_i2spcm_config method will send 3 commands: HCI_VSC_WRITE_I2SPCM_INTERFACE_PARAM, HCI_VSC_WRITE_SCO_PCM_INT_PARAM, HCI_VSC_WRITE_PCM_DATA_FORMAT_PARAM. Each next command will be sent only if previous was sent successfully and controller responded with correct status. –°ontroller responds, but bt_hci blocks the very first event and SCO configuration fails.

We have 2 possible solutions here:
1) Understand why bt_hci blocks events... This is ideal solution, but not easy! bt_hci is a part of system bluetooth stack and bluetooth stack is huge!
2) Send all the necessary commands without waiting for response from bt controller. Yep, i know how it sounds but it works! At least for now...

I've implemented solution #2. Look at hw_config_continue_sco_setup method. It works just like the hw_set_SCO_codec method but doesn't wait for response from bt controller. Why the hw_set_SCO_codec? Because it sends one more command related to WBS before calling the hw_sco_i2spcm_config.

As i said before i think this solution is terrible. Here are my concerns about it:
1) Uncontrolled commands sent to bt controller. Who knows how long this will work...
2) Can be applied only for broadcom chips.

That's all I found at the moment. I will try to implement the solution #1, but I can't tell whether it will work. Feel free to contact me if you have any questions/ideas/improvements.
Many thank to devs who still support our old hammy! @razorloves, @amaces, @EnesSastim, @voidz777, @KiD3991, @Hannibal226, @hhrokarvi, @Sashko98 and many other! You guys are awesome! Thanks a lot for your work!!! All this would be impossible without you!!!

PS: Sorry for my terrible english
The Following 42 Users Say Thank You to z3DD3r For This Useful Post: [ View ] Gift z3DD3r Ad-Free
18th June 2019, 07:23 AM |#6  
Senior Member
Thanks Meter: 1,010
 
Donate to Me
More
Quote:
Originally Posted by z3DD3r

We have 2 possible solutions here:
1) Understand why bt_hci blocks events... This is ideal solution, but not easy! bt_hci is a part of system bluetooth stack and bluetooth stack is huge!
2) Send all the necessary commands without waiting for response from bt controller. Yep, i know how it sounds but it works! At least for now...

As i said before i think this solution is terrible. Here are my concerns about it:
1) Uncontrolled commands sent to bt controller. Who knows how long this will work...
2) Can be applied only for broadcom chips.

If i understand correctly this is just a warning that the hci module doesn't recognize the command, which I believe is normal since the call is not made from the bt stack( which is not quite needed at this point anyway).

What is curious to me is why are the VSCs even required. I mean I tried to replicate the exact clock/codec etc.. configuration as it would've been configured if the VSCs were send, in the vnd config and there was no change at all. Probably there is something in the hcd patch about this, which would explain why my attempt in the post above works for Galaxy Note 3 and doesn't work for us.(if i am right than your hack could be considered just as extended of the hcd patch.)
Broadcom's libbt-vendor is pretty much obsolete, thus it will be easier to maintain this hack in further OS versions. Changes to bt-stack to get this work would be just too much time consuming to maintain considering that the guys from Google working on the AOSP want as less VSCs as possible.

Read this https://source.android.com/devices/bluetooth just to see how the Bluetooth works,if you plan to retrieve the VSCs to bt stack.
The Following 24 Users Say Thank You to Sashko98 For This Useful Post: [ View ] Gift Sashko98 Ad-Free
18th June 2019, 08:47 AM |#7  
Junior Member
Flag Minsk
Thanks Meter: 403
 
More
Quote:
Originally Posted by Sashko98

If i understand correctly this is just a warning that the hci module doesn't recognize the command, which I believe is normal since the call is not made from the bt stack( which is not quite needed at this point anyway).

This is partly true. This warning means that HCI received event for command which was not sent from bt stack. Some commands are send directly from the VendorInterface class and should be handle only here.

Quote:
Originally Posted by Sashko98

What is curious to me is why are the VSCs even required. I mean I tried to replicate the exact clock/codec etc.. configuration as it would've been configured if the VSCs were send, in the vnd config and there was no change at all.

It is not enough to just setup the vnd config. U still need to call hw_sco_i2spcm_config or hw_set_SCO_codec. But as i described above these methods fails.

Quote:
Originally Posted by Sashko98

Probably there is something in the hcd patch about this, which would explain why my attempt in the post above works for Galaxy Note 3 and doesn't work for us.(if i am right than your hack could be considered just as extended of the hcd patch.)

You are right! This issue can be fixed new firmware or additional firmware prepatch. But we will never receive such update) I did one experiment. Your fixes + custom firmware for our chip downloaded from here = working bt calls But this way is more crazy that my current hack)))

Quote:
Originally Posted by Sashko98

Broadcom's libbt-vendor is pretty much obsolete, thus it will be easier to maintain this hack in further OS versions. Changes to bt-stack to get this work would be just too much time consuming to maintain considering that the guys from Google working on the AOSP want as less VSCs as possible.

Read this https://source.android.com/devices/bluetooth just to see how the Bluetooth works,if you plan to retrieve the VSCs to bt stack.

Looks like we don't need to change anything in bt stack. Seems i have found the real issue. Look at VendorInterface::HandleEvent method. Seems that this is an entry point for all events sent from controller. This method uses the internal_command to determine how the received event should be handled. internal_command is populated inside of transmit_cb which is called from the libbt-vendor. So, what happens if someone will send 2 commands one after another? First command will be recorded into the internal_command var and the second command will be recorded to internal_command var. Second command will overwrite the infrormation about first. And since the communication is made via UART, controller will sent us response for first command (which is already gone) and then response for second command. Thats why nothing works! Thats why i saw that strange lines in logcat!!!

All that means that your fix should work. U just need to improve it a bit:
1. android_hardware_interfaces. Move lib_interface_->op(BT_VND_OP_SCO_CFG, nullptr); right after the lib_interface_->op(BT_VND_OP_LPM_SET_MODE, &mode);
2. c0d86f. Call the hw_set_SCO_codec for PCM instead of hw_sco_i2spcm_config

I have not tried it myself yet. But logs and logic seems correct. Bt calls issue may be not fixed cos of initialization sequence, but all callbacks should be called correctly.

---------- Post added at 08:47 AM ---------- Previous post was at 08:37 AM ----------

Hmm, seems that based on my finding i can improve my initial solution. At least i can made controllable configuration of the SCO with all required callbacks! Will try it today...
The Following 26 Users Say Thank You to z3DD3r For This Useful Post: [ View ] Gift z3DD3r Ad-Free
18th June 2019, 10:09 AM |#8  
Senior Member
Thanks Meter: 1,010
 
Donate to Me
More
Quote:
Originally Posted by z3DD3r

This is partly true. This warning means that HCI received event for command which was not sent from bt stack. Some commands are send directly from the VendorInterface class and should be handle only here.

The VendorInterface still comunicates with the bt stack via the hci_layer.

Quote:
Originally Posted by z3DD3r

It is not enough to just setup the vnd config. U still need to call hw_sco_i2spcm_config or hw_set_SCO_codec. But as i described above these methods fails.

You are right! This issue can be fixed new firmware or additional firmware prepatch. But we will never receive such update) I did one experiment. Your fixes + custom firmware for our chip downloaded from here = working bt calls But this way is more crazy that my current hack)))

In ideal case the hcd patch wouldn't need VSCs for such configuration, because It would've already been configured(what you tried with the custom patch just proves it). Appereantly Xperia Z3(shinano) is using its own solution by configuring the controller using bt drivers link. Perhaps this is why it is the only device I know of with BCM4339 Wifi/bt chip which didn't have any issues with bt-sco. Their code compiles perfectly with our kernel, but there are many init changes needed to happen to make it work.

Quote:
Originally Posted by z3DD3r

Looks like we don't need to change anything in bt stack. Seems i have found the real issue. Look at VendorInterface::HandleEvent method. Seems that this is an entry point for all events sent from controller. This method uses the internal_command to determine how the received event should be handled. internal_command is populated inside of transmit_cb which is called from the libbt-vendor. So, what happens if someone will send 2 commands one after another? First command will be recorded into the internal_command var and the second command will be recorded to internal_command var. Second command will overwrite the infrormation about first. And since the communication is made via UART, controller will sent us response for first command (which is already gone) and then response for second command. Thats why nothing works! Thats why i saw that strange lines in logcat!!!

If there is any race happening I think it should be handled by the VendorInterface, thought looking at the VendorInterface::HandleIncomingEvent method in vendor_interface.cc it is already handling such cases.
On Nougat the I2S/PCM interface was configured only when sco connection was established, if you look at the first eSCO commit you'll see that the initial idea was to keep the pre-SCO vendor setup link, thus I I used to be focused pretty much on bringing this back, till I understood there is no point, as it would require changes not only to the bt stack, but to Bluetooth app aswell.
As I said its just consumes too much time, not only to do it successfully, but to maintain it.

Quote:
Originally Posted by z3DD3r

All that means that your fix should work. U just need to improve it a bit:
1. android_hardware_interfaces. Move lib_interface_->op(BT_VND_OP_SCO_CFG, nullptr); right after the lib_interface_->op(BT_VND_OP_LPM_SET_MODE, &mode);
2. c0d86f. Call the hw_set_SCO_codec for PCM instead of hw_sco_i2spcm_config
..

hw_set_SCO_codec is useless at this point, as everything goes back to hw_sco_i2spcm_config to configure sample rate for the required codec. The clock rate is the same regardless of the codec.
On my local builds I moved lib_interface_->op(BT_VND_OP_SCO_CFG, nullptr); to the end of the method. Just for the tests once I put it even in VendorInterface;;Open, doesn't really matter where it is as long as it is called. The problem is that the callback methods arent reached. I tried sending BT_VND_OP_SET_AUDIO_STATE opcode command to start the whole sequene, but it doesnt get past the first send VSC(HCI_VSC_ENABLE_WBS) I believe it was, exactly due to the cbacks.
The Following 27 Users Say Thank You to Sashko98 For This Useful Post: [ View ] Gift Sashko98 Ad-Free
18th June 2019, 11:11 AM |#9  
Junior Member
Flag Minsk
Thanks Meter: 403
 
More
Quote:
Originally Posted by Sashko98

In ideal case the hcd patch wouldn't need VSCs for such configuration, because It would've already been configured(what you tried with the custom patch just proves it). Appereantly Xperia Z3(shinano) is using its own solution by configuring the controller using bt drivers [url=https://github.com/omnirom/android_kernel_sony_msm8974/tree/android-9.0/drivers/bluetooth]. Perhaps this is why it is the only device I know of with BCM4339 Wifi/bt chip which didn't have any issues with bt-sco. Their code compiles perfectly with our kernel, but there are many init changes needed to happen to make it work.

I know another device - LG G2. Own bt driver can work, but it looks very complicated to me...

Quote:
Originally Posted by Sashko98

If there is any race happening I think it should be handled by the VendorInterface, thought looking at the VendorInterface::HandleIncomingEvent() method in vendor_interface.cc it is already handling such cases.

I don't see any race conditions here. Just a simple mistake. Only one variable is used instead of queue. Maybe this interface wasn't designed to handle such cases...

Quote:
Originally Posted by Sashko98

On Nougat the I2S/PCM interface was configured only when sco connection was established, if you look at the first eSCO commit you'll see that the initial idea was to keep the pre-SCO vendor setup link, thus I I used to be focused pretty much on bringing this back, till I understood there is no point, as it would require changes not only to the bt stack, but to Bluetooth app aswell.
As I said its just consumes too much time, not only to do it successfully, but to maintain it.

Fully agree with you. Maintaining all those changes will be painful...

Quote:
Originally Posted by Sashko98

hw_set_SCO_codec is useless at this point, as everything goes back to hw_sco_i2spcm_config to configure sample rate for the required codec. The clock rate is the same regardless of the codec.

Who knows. I'm using it cos BT_VND_OP_SET_AUDIO_STATE command actually call hw_set_SCO_codec and not the hw_sco_i2spcm_config. hw_set_SCO_codec sends one additional command to enable/disable WBS. It may be not necessary for Nexus 5, but it can be necessary for other devices. In any case i think we should make this behavior configurable.

Quote:
Originally Posted by Sashko98

On my local builds I moved lib_interface_->op(BT_VND_OP_SCO_CFG, nullptr); to the end of the method. Just for the tests once I put it even in VendorInterface:pen(), doesn't really matter where it is as long as it is called. The problem is that the callback methods arent reached. I tried sending BT_VND_OP_SET_AUDIO_STATE opcode command to start the whole sequene, but it doesnt get past the first send VSC(HCI_VSC_ENABLE_WBS) I believe it was.

This is very strange. Look at my logcat (LOS wit BT fix):
Code:
06-18 09:06:15.850 I/bt_hwcfg(7282): hw_config_continue_sco_setup: set SCO related hardware settings
06-18 09:06:15.850 I/bt_hwcfg(7282): hw_config_continue_sco_setup: set SCO codec: 0x1
06-18 09:06:15.850 D/[email protected](7282): buffer_alloc_cb pts: 0x9f483e60, size: 14
06-18 09:06:15.850 D/[email protected](7282): transmit_cb opcode: 0xfc7e, ptr: 0x9f483e60, cb: 0x8b2cfcf9 - First opcode from hw_set_SCO_codec
06-18 09:06:15.850 I/bt_hwcfg(7282): hw_config_continue_sco_setup: set SCO I2S/PCM codec: 0x1
06-18 09:06:15.850 D/[email protected](7282): buffer_alloc_cb pts: 0x9f483e60, size: 15
06-18 09:06:15.850 I/bt_hwcfg(7282): hw_config_continue_sco_setup: I2SPCM config {0x0, 0x0, 0x0, 0x4}
06-18 09:06:15.850 D/[email protected](7282): transmit_cb opcode: 0xfc6d, ptr: 0x9f483e60, cb: 0x8b2cfcf9
06-18 09:06:15.850 D/[email protected](7282): buffer_alloc_cb pts: 0x9f483e60, size: 16
06-18 09:06:15.850 I/bt_hwcfg(7282): hw_config_continue_sco_setup: SCO PCM configure {0x0, 0x4, 0x0, 0x0, 0x0}
06-18 09:06:15.850 D/[email protected](7282): transmit_cb opcode: 0xfc1c, ptr: 0x9f483e60, cb: 0x8b2cfcf9
06-18 09:06:15.850 D/[email protected](7282): buffer_alloc_cb pts: 0x9f483e60, size: 16
06-18 09:06:15.850 I/bt_hwcfg(7282): hw_config_continue_sco_setup: SCO PCM data format {0x0, 0x0, 0x3, 0x0, 0x0}
06-18 09:06:15.850 D/[email protected](7282): transmit_cb opcode: 0xfc1e, ptr: 0x9f483e60, cb: 0x8b2cfcf9
06-18 09:06:15.850 I/bt_hwcfg(7282): hw_config_continue_sco_setup: finish
06-18 09:06:15.850 D/[email protected](7282): firmware_config_cb result: 0
06-18 09:06:15.850 D/[email protected](7282): OnFirmwareConfigured result: 0
06-18 09:06:15.850 I/[email protected](7282): Firmware configured in 0.635s
06-18 09:06:15.850 D/[email protected](7282): OnFirmwareConfigured: lpm_timeout_ms 1500
06-18 09:06:15.850 I/bt_hci  (7282): event_finish_startup
06-18 09:06:15.850 D/[email protected](7282): buffer_alloc_cb pts: 0x9f495958, size: 23
06-18 09:06:15.850 I/bt_core_module(7282): module_start_up Started module "hci_module"
06-18 09:06:15.850 D/[email protected](7282): transmit_cb opcode: 0xfc27, ptr: 0x9f495958, cb: 0x8b2cf4f9
06-18 09:06:15.850 D/[email protected](7282): OnFirmwareConfigured Calling StartLowPowerWatchdog()
06-18 09:06:15.851 D/[email protected](7282): sco_config_cb result: 0
06-18 09:06:15.851 D/[email protected](7282): OnScoConfigured result: 0
06-18 09:06:15.851 D/[email protected](7282): buffer_free_cb ptr: 0x9f483e50
06-18 09:06:15.851 D/[email protected](7282): internal_command_event_match internal_command.opcode = FC27 opcode = fc7e  - First event from bt controller
06-18 09:06:15.851 I/bt_osi_thread(7282): run_thread: thread id 7330, thread name bt_workqueue started
06-18 09:06:15.851 D/[email protected](7282): event_cb_ called
06-18 09:06:15.851 W/bt_hci  (7282): filter_incoming_event command complete event with no matching command (opcode: 0xfc7e).
06-18 09:06:15.851 I/        (7282): [0618/090615.851280:INFO:btu_task.cc(107)] Bluetooth chip preload is complete
06-18 09:06:15.851 I/        (7282): [0618/090615.851843:INFO:gatt_api.cc(948)] GATT_Register 81818181-8181-8181-8181-818181818181
06-18 09:06:15.851 I/        (7282): [0618/090615.851972:INFO:gatt_api.cc(968)] allocated gatt_if=1
06-18 09:06:15.852 I/        (7282): [0618/090615.852038:INFO:gatt_api.cc(161)] GATTS_AddService
06-18 09:06:15.852 I/        (7282): [0618/090615.852094:INFO:gatt_api.cc(265)] GATTS_AddService: service parsed correctly, now starting
06-18 09:06:15.852 I/        (7282): [0618/090615.852276:INFO:gatt_api.cc(948)] GATT_Register 82828282-8282-8282-8282-828282828282
06-18 09:06:15.852 I/        (7282): [0618/090615.852333:INFO:gatt_api.cc(968)] allocated gatt_if=2
06-18 09:06:15.852 I/        (7282): [0618/090615.852402:INFO:gatt_api.cc(161)] GATTS_AddService
06-18 09:06:15.852 I/        (7282): [0618/090615.852455:INFO:gatt_api.cc(265)] GATTS_AddService: service parsed correctly, now starting
06-18 09:06:15.852 I/bt_bte  (7282): BTE_InitTraceLevels -- TRC_HCI : Level 2
06-18 09:06:15.852 I/bt_bte  (7282): BTE_InitTraceLevels -- TRC_L2CAP : Level 2
06-18 09:06:15.852 I/bt_bte  (7282): BTE_InitTraceLevels -- TRC_RFCOMM : Level 2
06-18 09:06:15.852 I/bt_bte  (7282): BTE_InitTraceLevels -- TRC_AVDT : Level 2
06-18 09:06:15.852 I/bt_bte  (7282): BTE_InitTraceLevels -- TRC_AVRC : Level 2
06-18 09:06:15.852 I/bt_bte  (7282): BTE_InitTraceLevels -- TRC_A2D : Level 2
06-18 09:06:15.852 I/bt_bte  (7282): BTE_InitTraceLevels -- TRC_BNEP : Level 2
06-18 09:06:15.852 I/bt_bte  (7282): BTE_InitTraceLevels -- TRC_BTM : Level 2
06-18 09:06:15.852 I/bt_bte  (7282): BTE_InitTraceLevels -- TRC_HID_HOST : Level 2
06-18 09:06:15.852 I/bt_bte  (7282): BTE_InitTraceLevels -- TRC_PAN : Level 2
06-18 09:06:15.852 I/bt_bte  (7282): BTE_InitTraceLevels -- TRC_SDP : Level 2
06-18 09:06:15.852 I/bt_bte  (7282): BTE_InitTraceLevels -- TRC_SMP : Level 2
06-18 09:06:15.852 I/bt_bte  (7282): BTE_InitTraceLevels -- TRC_HID_DEV : Level 2
06-18 09:06:15.852 I/bt_bte  (7282): BTE_InitTraceLevels -- TRC_BTAPP : Level 2
06-18 09:06:15.852 I/bt_bte  (7282): BTE_InitTraceLevels -- TRC_BTIF : Level 2
06-18 09:06:15.853 I/bt_osi_thread(7282): run_thread: thread id 7331, thread name btu message loop started
06-18 09:06:15.853 D/[email protected](7282): internal_command_event_match internal_command.opcode = FC27 opcode = fc6d - Second one
06-18 09:06:15.853 D/[email protected](7282): event_cb_ called
06-18 09:06:15.853 W/bt_hci  (7282): filter_incoming_event command complete event with no matching command (opcode: 0xfc6d).
06-18 09:06:15.853 D/[email protected](7282): internal_command_event_match internal_command.opcode = FC27 opcode = fc1c
06-18 09:06:15.853 D/[email protected](7282): event_cb_ called
06-18 09:06:15.853 W/bt_hci  (7282): filter_incoming_event command complete event with no matching command (opcode: 0xfc1c).
06-18 09:06:15.853 D/[email protected](7282): internal_command_event_match internal_command.opcode = FC27 opcode = fc1e
06-18 09:06:15.853 D/[email protected](7282): event_cb_ called
06-18 09:06:15.853 W/bt_hci  (7282): filter_incoming_event command complete event with no matching command (opcode: 0xfc1e).
06-18 09:06:15.853 D/[email protected](7282): internal_command_event_match internal_command.opcode = FC27 opcode = fc27
06-18 09:06:15.853 I/bt_osi_thread(7282): run_thread: thread id 7332, thread name module_wrapper started
06-18 09:06:15.853 D/[email protected](7282): internal_command.bc called
internal_command.opcode doesn't match to the opcode received from bt controller. All events related to sco configuration will be handled by HCI. But HCI doesn't know anything about these commands and events (filter_incoming_event command complete event with no matching command in the log). Actually FC27 is HCI_VSC_WRITE_SLEEP_MODE. Seems that someone else sends this opcode to controller. I think that this can happens only after firmware configuration. We can try to postpone call of the initialize_complete_cb_ until sco configuration finish.
The Following 23 Users Say Thank You to z3DD3r For This Useful Post: [ View ] Gift z3DD3r Ad-Free
18th June 2019, 11:50 AM |#10  
Senior Member
Thanks Meter: 1,010
 
Donate to Me
More
Quote:
Originally Posted by z3DD3r

This is very strange. Look at my logcat (LOS wit BT fix):


internal_command.opcode doesn't match to the opcode received from bt controller. All events related to sco configuration will be handled by HCI. But HCI doesn't know anything about these commands and events (filter_incoming_event command complete event with no matching command in the log). Actually FC27 is HCI_VSC_WRITE_SLEEP_MODE. Seems that someone else sends this opcode to controller. I think that this can happens only after firmware configuration. We can try to postpone call of the initialize_complete_cb_ until sco configuration finish.

Its probably because you sent the VSCs directly from libbt-vendor, rather than sending an opcode command from VendorInterface, which then sends VSCs, and thus the VendorInterface considers the last internal opcode(BT_VND_OP_LPM_SET_MODE in this case) saved, as the next opcode commands which are being received.

If these logs bug you so much, just edit small part of the bt_vendor_brcm.c and include named by you opcode command which points to the hw_config_continue method, then call it from the VendorInterface.
If you do this then you should partially revert your commit, and set the firmware configuration as it was before, but then again it doesn't matter where the I2S/PCM interface is configured, what matters most is that it is configured.
The Following 22 Users Say Thank You to Sashko98 For This Useful Post: [ View ] Gift Sashko98 Ad-Free
18th June 2019, 04:03 PM |#11  
Junior Member
Flag Minsk
Thanks Meter: 403
 
More
Quote:
Originally Posted by Sashko98

Its probably because you sent the VSCs directly from libbt-vendor, rather than sending an opcode command from VendorInterface, which then sends VSCs, and thus the VendorInterface considers the last internal opcode(BT_VND_OP_LPM_SET_MODE in this case) saved, as the next opcode commands which are being received.

If these logs bug you so much, just edit small part of the bt_vendor_brcm.c and include named by you opcode command which points to the hw_config_continue method, then call it from the VendorInterface.
If you do this then you should partially revert your commit, and set the firmware configuration as it was before, but then again it doesn't matter where the I2S/PCM interface is configured, what matters most is that it is configured.

Seems that we a talking about different things. It really doesn't matter where the I2S/PCM interface is configured. It matters when!

Good news!
I've managed to improve initial solution!

Commit:
78d62ad58da101371822cee107f7759841d2744b

Changes:
No more memory leaks.
No more uncontrolled commands to bt chip. Each sent command receives callback and handles it appropriately.
Ability to configure codec configuration through the vnd config. We can use only i2spcm or wbs+i2spcm.

@razorloves, what do you think about it?
I can share a test build if anyone is interested.
The Following 44 Users Say Thank You to z3DD3r For This Useful Post: [ View ] Gift z3DD3r Ad-Free
Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes