• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 51 subscribers
  • Views 2031 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

No call audio - "FBF not enough available slots for the next scheduling of (E)SCO instance"

dwf
Intellectual 890 points

When connecting 4 devices to CC2564B and I wish to have 2 of them in call at once (transferring audio to each other), sometimes I don't get any call audio, and the following warning floods the logger window:

*** WARNING *** FBF not enough available slots for the next scheduling of (E)SCO instance

I've been able to work around it manually by noticing this error occurring in the logger and closing the SCO links and reopening them. But in those cases, it occurs with those two devices every time I try to start the call for that session, and I have to close and reopen the SCO links every time to get the audio working. However, if I start a call on the other two devices that are connected instead, there is no problem.

What can I do to avoid this error? I can't automatically detect that the error is occurring, since there's no indication sent to me via the Bluetooth stack (the artist formerly known as Bluetopia)

Here is the rough sequence of events that occurs:

1. I receive status of incoming call from remote 2 via HFP, stop any A2DP streams and reconfigure codec

2. HFRE_Setup_Audio_Connection (HCI_Setup_Synchronous_Connection) to remote 1 (eSCO)

3. HCI_Synchronous_Connection_Complete_Event (success)

4. HCI_Connection_Request_Event from remote 2 (eSCO)

5. HCI_Synchronous_Connection_Complete_Event (success)

6. Shortly thereafter, warning starts flooding window

Here is an excerpt

430064 01/22/16 09:39:11.389   +0:05:56.474 0x00045A0F 0x00045A0F HCI_Setup_Synchronous_Connection ----> 430065 01/22/16 09:39:11.389   +0:05:56.474 0x00045A10 0x00045A10 <---- HCI_Command_Status_Event 430066 01/22/16 09:39:11.389   +0:05:56.474 0x00045A13 0x00045A13 LMP_eSCO_link_req ----> eSCO handle = 1, eSCO LT_ADDR = 4, timing control flags = 0, D-eSCO = 0, T-eSCO = 12, W-eSCO = 2, SCO packet type M->S = 38, SCO packet type S->M = 38, Packet Length M->S = 60, Packet Length S->M = 60, air mode = 2, negotiation state = 0 430087 01/22/16 09:39:11.413   +0:05:56.498 0x00045A27 0x00045A27 <---- LMP_eSCO_link_req eSCO handle = 1, eSCO LT_ADDR = 4, timing control flags = 0, D-eSCO = 0, T-eSCO = 6, W-eSCO = 2, SCO packet type M->S = 7, SCO packet type S->M = 7, Packet Length M->S = 30, Packet Length S->M = 30, air mode = 2, negotiation state = 4 430088 01/22/16 09:39:11.413   +0:05:56.498 0x00045A29 0x00045A29 LMP_eSCO_link_req ----> eSCO handle = 1, eSCO LT_ADDR = 4, timing control flags = 0, D-eSCO = 2, T-eSCO = 6, W-eSCO = 2, SCO packet type M->S = 7, SCO packet type S->M = 7, Packet Length M->S = 30, Packet Length S->M = 30, air mode = 2, negotiation state = 1 430089 01/22/16 09:39:11.413   +0:05:56.498 0x00045A2C 0x00045A2C <---- LMP_accepted_ext escape opcode = 127, extended opcode = 12 430090 01/22/16 09:39:11.414   +0:05:56.499 0x00045A2C 0x00045A2C <---- HCI_Synchronous_Connection_Complete_Event 430128 01/22/16 09:39:11.423   +0:05:56.508 0x00045A2D 0x00045A2D <---- HCI_Max_Slots_Change_Event 430129 01/22/16 09:39:11.424   +0:05:56.509 0x00045A2D 0x00045A2D <---- HCI_Max_Slots_Change_Event 430130 01/22/16 09:39:11.425   +0:05:56.510 0x00045A2E 0x00045A2E <---- HCI_Max_Slots_Change_Event 430131 01/22/16 09:39:11.425   +0:05:56.510 0x00045A2E 0x00045A2E <---- HCI_Max_Slots_Change_Event 430132 01/22/16 09:39:11.425   +0:05:56.510 0x00045A2F 0x00045A2F LMP_max_slots ----> Max Slots = 1 430133 01/22/16 09:39:11.425   +0:05:56.510 0x00045A30 0x00045A30 LMP_max_slots ----> Max Slots = 1 430134 01/22/16 09:39:11.425   +0:05:56.510 0x00045A30 0x00045A30 <---- LMP_max_slots Max Slots = 3 430135 01/22/16 09:39:11.425   +0:05:56.510 0x00045A33 0x00045A33 LMP_max_slots ----> Max Slots = 1 430178 01/22/16 09:39:11.440   +0:05:56.525 0x00045A48 0x00045A48 <---- LMP_max_slots_req Max Slots = 5 430179 01/22/16 09:39:11.440   +0:05:56.525 0x00045A4A 0x00045A4A LMP_not_accepted ----> Opcode = LMP_max_slots_req, Reason = Unspecified Error 430201 01/22/16 09:39:11.483   +0:05:56.568 0x00045A66 0x00045A66 LMP_max_slots ----> Max Slots = 1 430314 01/22/16 09:39:11.885   +0:05:56.970 0x00045B32 0x00045B32 <---- LMP_max_slots_req Max Slots = 5 430315 01/22/16 09:39:11.885   +0:05:56.970 0x00045B34 0x00045B34 LMP_not_accepted ----> Opcode = LMP_max_slots_req, Reason = Unspecified Error 430316 01/22/16 09:39:11.885   +0:05:56.970 0x00045B38 0x00045B38 <---- LMP_eSCO_link_req eSCO handle = 0, eSCO LT_ADDR = 0, timing control flags = 0, D-eSCO = 0, T-eSCO = 12, W-eSCO = 2, SCO packet type M->S = 38, SCO packet type S->M = 38, Packet Length M->S = 60, Packet Length S->M = 60, air mode = 2, negotiation state = 0 430317 01/22/16 09:39:11.886   +0:05:56.971 0x00045B38 0x00045B38 <---- HCI_Connection_Request_Event 430318 01/22/16 09:39:11.887   +0:05:56.972 0x00045B39 0x00045B39 HCI_Read_Voice_Setting ----> 430319 01/22/16 09:39:11.888   +0:05:56.973 0x00045B39 0x00045B39 <---- HCI_Command_Complete_Read_Voice_Setting_Event 430320 01/22/16 09:39:11.888   +0:05:56.973 0x00045B3A 0x00045B3A HCI_Accept_Synchronous_Connection_Request ----> 430352 01/22/16 09:39:11.896   +0:05:56.981 0x00000000 0x00000000 <---- HCI_Protocol_Viewer_Message_Was_Dropped_Event 430353 01/22/16 09:39:11.896   +0:05:56.981 0x00045B41 0x00045B41 LMP_eSCO_link_req ----> eSCO handle = 2, eSCO LT_ADDR = 5, timing control flags = 0, D-eSCO = 2, T-eSCO = 12, W-eSCO = 2, SCO packet type M->S = 38, SCO packet type S->M = 38, Packet Length M->S = 60, Packet Length S->M = 60, air mode = 2, negotiation state = 1 430354 01/22/16 09:39:11.896   +0:05:56.981 0x00045B46 0x00045B46 <---- LMP_accepted_ext escape opcode = 127, extended opcode = 12 430355 01/22/16 09:39:11.897   +0:05:56.982 0x00045B46 0x00045B46 <---- HCI_Synchronous_Connection_Complete_Event 430356 01/22/16 09:39:11.897   +0:05:56.982 0x00045B47 0x00045B47 <---- LMP_max_slots_req Max Slots = 3 430357 01/22/16 09:39:11.897   +0:05:56.982 0x00045B4A 0x00045B4A LMP_not_accepted ----> Opcode = LMP_max_slots_req, Reason = Unspecified Error 430512 01/22/16 09:39:11.901   +0:05:56.986 *** WARNING *** FBF not enough available slots for the next scheduling of (E)SCO instance

  • 0
    TI__Guru* 85400 points
    Hi,

    Can you please attach the full logger logs?

    Regards,
    Gigi Joseph.
  • 0 in reply to Joseph Gigi
    Intellectual 890 points

    First call session with first set of devices at 281890... issue occurred

    Second-third call session with second set of devices, around log numbers 357632 and 367698...call audio worked fine

    hci_log_no_slots_during_call.zip

  • 0 in reply to dwf
    TI__Guru* 85400 points
    Hi,

    Please see the below reply from our firmware expert:

    ***
    The reason that it’s not working is that practically the BW is over utilized.
    - You have 4 ACL connections that need to be maintained
    - First voice connection is established with EV3 and 2 retransmissions. Our controller actually tries to establish the connection with 2EV3, but the remote refuses, and as a result EV3 is established. This means that every 3 frames, there’s a voice packet. If you consider 2 retransmissions, the BW is fully occupied.
    - Second voice connection is established with 2EV3 and 2 retransmissions, but then again, the BW is already fully utilized.

    I could see that our controller is master on all connections which is good. I suggest that you enable only 2EV3 packet type, so only every 6 frames there’s a packet and not every 3 as opposed to EV3. All headsets today should support 2EV3, so that should address this issue.
    ***

    Regards,
    Gigi Joseph.
  • 0 in reply to Joseph Gigi
    Intellectual 890 points

    Thanks! Makes sense.

    How can I restrict packet type to 2EV3 using the TI Bluetooth stack? Is there a command in the API or is it a VS command that I need to implement? I couldn't find one off the bat when searching the VS HCI commands page and the BluetopiaCoreAPI.pdf for EV3 or 2EV3 -- only found EV3 in HCI_Setup_Synchronous_Connection, but didn't see a 2EV3 setting in there. I'm using the HFRE API to handle the SCO connection rather than the lower level API

  • 0 in reply to dwf
    TI__Guru* 85400 points

    Hi,

    Yes, you should use the HCI_Setup_Synchronous_Connection() API and set the "PacketType" accordingly.
    The PacketType field is defined as:

    Value Parameter Description
    0x0001 HV1 may be used.
    0x0002 HV2 may be used.
    0x0004 HV3 may be used.
    0x0008 EV3 may be used.
    0x0010 EV4 may be used.
    0x0020 EV5 may be used.
    0x0040 2-EV3 may not be used.
    0x0080 3-EV3 may not be used.
    0x0100 2-EV5 may not be used.
    0x0200 3-EV5 may not be used.


    The HFRE API won't be appropriate.

    Regards,
    Gigi Joseph.

  • 0 in reply to Joseph Gigi
    Intellectual 890 points

    Here's the error I get when trying to open a SCO connection to the headset, with the 0x0008 bit cleared in the PacketType field:

    SCO Interval Rejected

    Attached is the HCI trace

    In addition, since I am using the HFRE API to communicate with the phone, since the phone is responsible for initiating the SCO link, and since the HFRE API registers synchronous connection request callbacks, there is no way I can guarantee that the phone will use 2EV3, correct? If I get HFRE event etHFRE_Audio_Connection_Indication, will I need to close that connection and then manually set up a SCO link to the phone in this same way to ensure that it does not use EV3?

    hci_log_sco_interval_rejected.zip

  • 0 in reply to dwf
    TI__Guru* 85400 points
    Hi,

    To handle incoming SCO connections, you must use SCO_Register_Synchronous_Connect_Request_Callback() & SCO_Accept_Synchronous_Connection() . Please check the "BluetopiaCoreAPI.pdf" documentation for more details.

    It looks like your PacketType above is wrong.
    Kindly try with "0x0380"

    Regards,
    Gigi Joseph.
  • 0 in reply to Joseph Gigi
    Intellectual 890 points
    Sorry I took so long, but the resolution (for now) appears to be force everything to SCO, rather than eSCO. The headset in question supports the HV3 packet type, but not 2EV3 (no matter how hard I tried--even 0x380), and I continue to allow the phone to set up the SCO connection through the HFRE API and negotiate 2EV3. The Bluetooth chip is still able to handle scheduling everything in that configuration, as far as I can tell.

    I don't know what the ultimate disadvantage is to losing the retransmission capability to the headset, but whatever it is, it's better than no call audio at all.

    Thanks for all your help! Much appreciated.