cancel
Showing results for 
Search instead for 
Did you mean: 

LE Audio QoS Configuration Failed in STM32WBA55G-DK1

Jetson
Associate

When I checked the LE Audio unicast operation of the provided project on the STM32WBA55G-DK1, I noticed a strange behavior.

For the peripheral, the PAC settings are Sink 2, Src 1, but when I perform QoS Configuration using the following procedure, the notification for the QoS Config of Sink2 is not notified to the central.

1. QoS Config Src 1 -> QoS Configuration Notification

2. QoS Config Sink 1 -> QoS Configuration Notification

3. Qos Config Sink 2 -> No Notification

 

Also, for the central, the PAC settings are Src2, Sink1, but for some reason, QoS Config is not executed for Sink even though the peripheral actually supports Sink.

From the above behavior of the peripheral and central, I suspect that the implementation is such that QoS settings cannot be set to more than three EPs, or that it cannot be used properly if there is only one EP for both Sink and Src.

 

As for the UI to be output to the LCD,

in the case of the central, it seems that only the sending UI is supported, and in the case of the peripheral, it only supports the receiving UI, so I imagine that it is not possible to set an EP in the opposite direction.

Could you please comment on the above, including the actual operating specifications?

 

[Srouce]

https://github.com/STMicroelectronics/STM32CubeWBA.git

 

[Project]

Projects\STM32WBA55G-DK1\Applications\BLE\BLE_Audio_TMAP_Peripheral

Projects\STM32WBA55G-DK1\Applications\BLE\BLE_Audio_TMAP_Central

4 REPLIES 4
Joe WILLIAMS
ST Employee

Hi Jetson

This post has been escalated to the ST Online Support Team for additional assistance.  We'll contact you directly.

Regards

Joe

STMicro support

Jetson
Associate

Additional information.

When connecting STM32 as a peripheral, the QoS Configuration Notification value is as follows, and it seems that it cannot be set.

ASE ID: 0x01 (Sink)
ASE Response Code: Unsupported Configuration (0x07)
ASE Response Reason: Presentation Delay (0x09)
*Due to the data received from the central side

The QoS Configuration Notification, which is the expected behavior after that, was only ASE ID: 0x03 (Source).

However, strangely, even when checking the STM debug log,
even the processing in case CAP_UNICAST_PREFERRED_QOS_REQ_EVT:
info->pResp, info->pReason are set to 0x00, but the values ​​actually notified are Response=0x07, Reason=0x09.

 

[STM32 Peripheral Log]

CAP Event : 0x0D
Preferred Server QoS Settings is requested for ASE ID 3 (Type 0x01)
Target Latency : 2
Target Phy 2 to achieve the Target Latency
Codec ID
Coding format : 0x06
Company id : 0x0000
VS codec id : 0x0000
Frequency : 3
Frame Duration : 0
Octets Per Codec Frame : 30
Codec Frame Blocks Per SDU : 1
Min Controller Delay in Source role 4623 us
Max Controller Delay in Source role 232500 us
Min Controller Delay in Sink role 6272 us
Max Controller Delay in Sink role 50000 us
Calculated SDU Interval : 7500 us
Computed Min Controller Delay with 2 Snk ASEs and 1 Src ASEs : 13167 us
WARNING : Computed Controller Delay Min ( 13167 us) could be higher than the frame duration (7.5 ms)
Submitted Min Presentation Delay 7510 us
Submitted Max Presentation Delay 232510 us
Resp:0, Reason:0
CAP Event : 0x0D
Preferred Server QoS Settings is requested for ASE ID 1 (Type 0x00)
Target Latency : 2
Target Phy 2 to achieve the Target Latency
Codec ID
Coding format : 0x06
Company id : 0x0000
VS codec id : 0x0000
Frequency : 8
Frame Duration : 0
Octets Per Codec Frame : 117
Codec Frame Blocks Per SDU : 1
Min Controller Delay in Source role 5793 us
Max Controller Delay in Source role 110000 us
Min Controller Delay in Sink role 5356 us
Max Controller Delay in Sink role 52500 us
Calculated SDU Interval : 7500 us
Computed Min Controller Delay with 2 Snk ASEs and 1 Src ASEs : 12505 us
WARNING : Computed Controller Delay Min ( 12505 us) could be higher than the frame duration (7.5 ms)
Submitted Min Presentation Delay 7510 us
Submitted Max Presentation Delay 52510 us
Resp:0, Reason:0
CAP Event : 0x13
ASE ID 3 [Type 0x01 ] with remote CAP Initiator on ConnHandle 0x0001 is in State 0x01
CAP Event : 0x13
ASE ID 1 [Type 0x00 ] with remote CAP Initiator on ConnHandle 0x0001 is in State 0x01
CAP Event : 0x13
ASE ID 3 [Type 0x01 ] with remote CAP Initiator on ConnHandle 0x0001 is in State 0x02
TMAP Linkup Complete Event with ConnHandle 0x0001 is received with status 0x91

Jetson
Associate

The ASE settings are Src1, Sink1, which is the behavior during debugging.

In the provided binaries, the ASE settings are Src1, Sink2.

CorentinS
ST Employee

Hello Jetson,

 

After checking your logs, we understood that you were trying to do a stream with

  • 1 ASE Source at 16kHz mono (1 channel)
  • 1 ASE Sink at 48kHz stereo (2 channels)
  • the frame duration at 7.5ms

With our current implementation & hardware, this stream is just above the limitations, but we have 2 responses for you do be able to do this type of stream:

 

1st part of the response to be able to have 2 different sampling frequencies at the same time:

  • We have the GMAP applications that are able to do it (on the STM32WBA65) but you can replicate this changes on the TMAP applications on STM32WBA55:
    • CODEC_LC3_NUM_SESSION should be set to 2 for increasing memory allocated for the Codec Manager.
    • adapt the application layer to force the SAI/I2S bus to run at the highest audio frequency (sink), and down-sample it to get the source audio buffer

2st part of the response for the audio quality:

  • Also, having 1 encoding stream at 16khZ & 2 decoding streams (because stereo) at 48kHz is refused because we are close to the limitations of our CPU (having to handle Link Layer + LC3)
  • We can propose 2 solutions to be able to have a bidirectional stream with stereo:
    • 1: Change the frame duration to 10ms (Source at 16_2 & Sink at 48_4)
    • 2: Decrease the Sink Audio Quality to 32kHz: (Sink at 32_1)

Thanks,