HAP Central start stream fail

[HuangFan]

Use example code BLE_Audio_HAP_Central to audio function. The Central may start the stream fail, though the BLE connect and GAP link returns are OK. and Once the stream start failed, the stream cannot be start forever, with the result "CAP Unicast Start Procedure is Complete with status 0x91".  Compared with the normal process the GAP link lack of CAP event 0x06, 0x12. 

I have to use aci_gap_clear_security_db()  then I can connect and start the stream successfully. And what's more, use aci_gap_remove_bonded_device() to remove the certain device and repairing cannot start the stream. It seems that there's some memory issues. 

log for stream start failed

[10:10:48.442]·¢¡ú¡ó{A\0v³
\0ÿÿ}¡õ
[10:10:48.445]ÊÕ¡û¡ôaci_gap_terminate_gap_proc() returns status 0x00
HAPAPP_StopScanning() returns status 0x00
Selected device 0
aci_gap_create_connection() returns status 0x00
{A\0w³
\0V˜}P_PROC_COMPLETE_VSEVT_CODE
>>== ACI_GAP_PROC_COMPLETE_VSEVT_CODE
>>== HCI_LE_ENHANCED_CONNECTION_COMPLETE_SUBEVT_CODE - Connection handle: 0x0001
     - Connection established with @:a4:90:ce:1e:a9:87
     - Connection Interval:   40.00 ms
     - Connection latency:    0
     - Supervision Timeout:   10000 ms
>>== device is already bonded
aci_gap_send_pairing_req returns 0
  Success: aci_gap_adv_set_enable stop

[10:10:48.726]ÊÕ¡û¡ô>>== ACI_GAP_PAIRING_COMPLETE_VSEVT_CODE
     - Pairing Success

Pairing Complete with connection handle 0x0001
GAF Profiles Mask 0x0A present in NVM
profiles 0x00 of the GAF are already linked on ConnHandle 0x0001
CAP_Linkup() for GAF restoration on ConnHandle 0x0001 for link mask 0x0A returns status 0x00

[10:10:48.848]ÊÕ¡û¡ôMTU = 247
  Success: aci_gatt_update_char_value BLOCKSIZE command
CAP Event : 0x12
ASE ID 5 [Type 0x01 ] with remote CAP Acceptor on ConnHandle 0x0001 is in State 0x00
CAP Event : 0x12
ASE ID 6 [Type 0x01 ] with remote CAP Acceptor on ConnHandle 0x0001 is in State 0x00
CAP Event : 0x0A
CAP Unicast Linkup Event with status 0x00

[10:10:48.968]ÊÕ¡û¡ôCAP Event : 0x02
Sink PAC Record from CAP Acceptor on ConnHandle 0x0001
Remote Record: 
    Supported Sample Freq: 
              48 kHz
    Supported Frame Duration: 
              7.5 ms
              10 ms
              Preferred 7.5 ms
    Supported Channel Counts: 
              1 Channel
    Supported Octets Per Codec Frame: 0x64004B
    Supported Max Codec Frame Per SDU: 2
    Supported Preferred Audio Contexts: 0x0098

[10:10:49.127]ÊÕ¡û¡ôCAP Event : 0x02
Sink PAC Record from CAP Acceptor on ConnHandle 0x0001
Remote Record: 
    Supported Sample Freq: 
              16 kHz
              24 kHz
              32 kHz
              48 kHz
    Supported Frame Duration: 
              7.5 ms
              10 ms
              Preferred 10 ms
    Supported Channel Counts: 
              1 Channel
    Supported Octets Per Codec Frame: 0x9B001E
    Supported Max Codec Frame Per SDU: 2
    Supported Preferred Audio Contexts: 0x0004

[10:10:49.567]ÊÕ¡û¡ôCAP Event : 0x03
Source PAC Record from CAP Acceptor on ConnHandle 0x0001
Remote Record: 
    Supported Sample Freq: 
              16 kHz
    Supported Frame Duration: 
              7.5 ms
              10 ms
              Preferred 7.5 ms
    Supported Channel Counts: 
              1 Channel
    Supported Octets Per Codec Frame: 0x28001E
    Supported Max Codec Frame Per SDU: 2
    Supported Preferred Audio Contexts: 0x0098

[10:10:49.727]ÊÕ¡û¡ôCAP Event : 0x03
Source PAC Record from CAP Acceptor on ConnHandle 0x0001
Remote Record: 
    Supported Sample Freq: 
              16 kHz
              24 kHz
              32 kHz
    Supported Frame Duration: 
              7.5 ms
              10 ms
              Preferred 10 ms
    Supported Channel Counts: 
              1 Channel
    Supported Octets Per Codec Frame: 0x500028
    Supported Max Codec Frame Per SDU: 2
    Supported Preferred Audio Contexts: 0x00D2

[10:10:50.446]ÊÕ¡û¡ôCAP Event : 0x39
Volume Control Profile is linked on ConnHandle 0x0001
CAP Event : 0x00
CAP Linkup Complete on Connhandle 0x0001 with status 0x00
Complete HAP Linkup on ConnHandle 0x0001 is started with status 0x00

[10:10:52.127]ÊÕ¡û¡ôHAP Linkup Complete Event with ConnHandle 0x0001 is received with status 0x00
HAP_HARC_ReadPresetsRequest() returns status 0x92

[10:10:54.362]·¢¡ú¡ó{A\0vµ

\0ÿÿ}¡õ
[10:10:54.366]ÊÕ¡û¡ôStart Telephony Stream
Start Telephony Stream
Set Start Stream for CAP Acceptor 0 on connHandle 0x0001 :
Sink Codec Conf :
    Audio Channel Allocation : 0x00000003
    Channel Per CIS : 1
    Sampling Freq : 0x03
Source Codec Conf :
    Audio Channel Allocation : 0x00000003
    Channel Per CIS : 1
    Sampling Freq : 0x03
CAP_Unicast_AudioStart() of 1 CAP Accceptors in Set Type 0x00 returns status 0x00
{A\0wµ
ÄT}
[10:10:59.485]ÊÕ¡û¡ôCAP Event : 0x0B
CAP Unicast Start Procedure is Complete with status 0x91

[TMANE.1]

Hi,

Both host stack and audio stack are storing information in NVM. They can be cleared respectively with  aci_gap_clear_security_db() and BLE_AUDIO_STACK_DB_ClearAllRecords().

But we have to understand if the ASE state misalignment could be the cause 

An air trace could help a lot, please note the connection is encrypted so you can use debug key (https://community.st.com/t5/stm32-mcus-wireless/how-to-get-ltk-long-term-key/m-p/821768)

BR,

[HuangFan]

Hi 

I've tested -use CAP_Linkup() with CompleteLinkMode set to 1, for several times and stream start fail never happens, but the linkup time will be much longer every time, for SDK 1.50 the time will 13s while for 1.80 the time is 6s.

Also I was in trouble to get the LTK for capture decryption. I added the following code at the end of Ble_Hci_Gap_Gatt_Init as suggested:

uint8_t a_sc_key_type[1];
a_sc_key_type[0] = 1;
aci_hal_write_config_data(CONFIG_DATA_SC_KEY_TYPE_OFFSET,1,a_sc_key_type);

It seems that the capture tools, Ellisys analyzer, still could not decrypt the traffic automatically. The link key should be input manually.

[HuangFan]

I've captured the air trace:

The first pairing:

 The second:

 

[HuangFan]

the capture files, one for OK, one for fail.

[TMANE.1]

Hello Huang Fan,

Thank you for the capture,

According to the air sniff traces, we can observe that the issue is due to a dealignments between the GATT databases of the two devices.

The first dealignment is related to the config descriptor of the GATT characteristics of the Audio services. The HAP Central has kept in memory that 'notification' is enabled for the Audio ATT characteristics from the first CAP linkup, but it is not done at the peripheral side. Consequently, when the HAP Central, during the streaming start procedure of the second connection, expects to receive a notification from the peripheral after a ASE Control operation, it never receives a feedback from the peripheral.

The Core specification says  "The Client Characteristic Configuration descriptor value shall be persistent across
connections for bonded devices." (Core Spec  - Vol 3 Part G 3.3.3.3), so the peripheral does not have the correct behavior. 

The second dealignment is related to the initial state of the Audio Stream Endpoint when the HAP Central starts the Stream Audio Start procedure : The HAP Central restores the ASE State during the CAP Linkup restoration in CODEC CONFIGURED State while the ASEs in Peripheral side are in IDLE State. 
Consequently, when the Audio Stream Start Procedure, the HAP Central performs a QoS Config operation with the ASEs but this operation is not permitted with ASE in IDLE State.

The change/reset of peripheral ASEs to Idle state should have been notified to the Central as well. 

It seems the peripheral does not store any data related to CAP linkup. Ensure your device has the last software version since VIVO may propose some updates.

Note the proposed workaround to use CAP_Linkup() with CompleteLinkMode will bypass this peripheral issue.

Best regards,

[HuangFan]

Hi,

Thanks for the  explanation of the issue.

It seems the peripheral not response the ASE operation as you mentioned. Though I can use CAP_Linkup() with Complete LinkMode, but the complete link will take more than 8 seconds very time which could be a disastrous user experience, while within 2 seconds for none complete link.  

I wonder that there must be other ways to link up with the headset. For I've used the headset with my phone and computer for more than half years, no issue happens. It's a pity that I cannot decrypt the air trace.  

[TMANE.1]

Hello,

The application is provided for demonstration and can be adapted to your needs. 

You can speed up the linkup by changing the connection interval from 30ms to 7.5ms (see HAPAPP_CreateConnection()).  

Still I would recommend to do a connection update (hci_le_connection_update()) at the end of the linkup to set a longer interval such 30 or 60ms for saving power consumption and having an ACL interval compatible with the ISO interval (7.5ms or 10ms for HAP audio configs)

Best regards,