Regarding the behavior of bt_audio_stream_start

[tommy]

The following phenomena have been observed in an anechoic chamber:

• Success: After the bt_audio_stream_start function is called, the stream_started_cb callback is invoked.
• Failure: After the bt_audio_stream_start function is called, the stream_stopped_cb callback is invoked, and the wireless connection is disconnected (this also occurs even in the chamber).

Question 1: In the link processing of the SDK2.3.0_nrf5340audio project, during the sequence of audio_stream processing*1, the stream_stopped_cb callback is called, and the behavior of disconnecting and reconnecting the wireless connection is repeated. Do you know the cause? *1: Refers to the bt_audio_stream_config function, bt_audio_stream_qos function, bt_audio_stream_enable function, and bt_audio_stream_start function.

Question 2: When the wireless connection is disconnected, bt_audio_stream_start returns to the beginning and starts the scanning process again. This takes a considerable amount of time, so if there is any workaround, please let me know.

[dejans]

Hi,

Can you provide more information about your testing environment and test setup?

Failure: After the bt_audio_stream_start function is called, the stream_stopped_cb callback is invoked, and the wireless connection is disconnected (this also occurs even in the chamber).

Can you elaborate on this Failure case and the difference compared to Success? What exactly do you consider failure and what do you expect to happen?

Best regards,
Dejan

[tommy]

Thank you for your reply.

Could you refer to the attached material?

[tommy]

Dejans,

Would it be possible to let us know how to output Logs of bt_audio_stream_config, bt_audio_stream_qos,bt_audio_stream_enable,bt_audio_stream_start?

Could you let us know the name and point of source code to be modified?

BR,

[dejans]

Hi,

tommy said:

Would it be possible to let us know how to output Logs of bt_audio_stream_config, bt_audio_stream_qos,bt_audio_stream_enable,bt_audio_stream_start?

You could try to use logging in a module. If you have for example LOG_MODULE_REGISTER(bt_xxxxx, CONFIG_BT_XXXXX_LOG_LEVEL) in your source file, you could use CONFIG_BT_XXXXX_LOG_LEVEL=4 in your prj.conf to get an output.

tommy said:

Could you let us know the name and point of source code to be modified?

I have discussed this with our developers. Based on your problem description, potential issue seems to be multifaceted - potentially caused by controller, host or application. Your NCS version uses deprecated audio controller. From NCS v2.3.0 to the newest NCS version, there have been many bug fixes and improvements in the host, controller and application. In addition, new controller is now used in the latest NCS version. Therefore, it is highly recommended that you upgrade to the newest NCS version.

Best regards,
Dejan

 

[tommy]

>Do you have an application log which you could send?

Here is the log gotten by EVK.
Is there anything you think might be the cause?

[dejans]

Hi,

Disconnections happen from controller side and restart of scanning probably happens on the application side. As you use deprecated controller which is not supported anymore, it is higly recommended that you update your NCS version.
Can you please update to the newest NCS version and provide newly obtained log?
Is there any difference in behavour when you use updated NCS version?

Best regards,
Dejan

[tommy]

dejans said:

Is there any difference in behavour when you use updated NCS version?

We have updated NCS to ver2.7.0 and tried the same test, and the disconnection didn't happen under the same environment.

[dejans]

Hi,

Thank you for the update.

Best regards,
Dejan