Bad quality of Audio stream on RF5340 Audio application - NCS v2.8.0

[Omri]

Hi,

I am using the nRF5340 Audio DK board with the nRF5340 Audio application under NCS v2.8.0 as a Unicast client.

I observed that changing the connection interval to a value other than 8 (10 ms) significantly degrades the quality of the LE audio stream.

particularly noticeable when transmitting a test tone.

The application is configured as a Unicast Client and connected to a pair of Starkey hearing aids.

Is it a known issue? Is there any potential fix for this?

The following is my prj.conf:

#
# Copyright (c) 2022 Nordic Semiconductor ASA
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#

# nRF5340 Audio
CONFIG_NRF5340_AUDIO=y
CONFIG_SAMPLE_RATE_CONVERTER=y
CONFIG_SAMPLE_RATE_CONVERTER_FILTER_SIMPLE=y

CONFIG_AUDIO_DEV=2
CONFIG_AUDIO_SOURCE_I2S=y
CONFIG_AUDIO_SAMPLE_RATE_16000_HZ=y
CONFIG_BT_BAP_UNICAST_16_2_1=y
CONFIG_MONO_TO_ALL_RECEIVERS=y
CONFIG_BT_AUDIO_BITRATE_UNICAST_SINK=32000
CONFIG_BT_AUDIO_RETRANSMITS=3
CONFIG_BT_AUDIO_MAX_TRANSPORT_LATENCY_MS=10
CONFIG_BT_DEVICE_NAME="Blaine H/As"

# General
CONFIG_DEBUG=y
CONFIG_DEBUG_INFO=y
CONFIG_ASSERT=y
CONFIG_STACK_USAGE=y
CONFIG_THREAD_RUNTIME_STATS=y
CONFIG_STACK_SENTINEL=y
CONFIG_INIT_STACKS=y

# Uart driver
CONFIG_SERIAL=y

# Logging
CONFIG_LOG=y
CONFIG_NEWLIB_LIBC_FLOAT_PRINTF=y
CONFIG_LOG_TAG_MAX_LEN=2
CONFIG_LOG_TAG_DEFAULT="--"
CONFIG_LOG_BACKEND_UART=y
CONFIG_LOG_BUFFER_SIZE=4096

# Use this for debugging thread usage
#CONFIG_LOG_THREAD_ID_PREFIX=y

# Console related defines
CONFIG_CONSOLE=y
CONFIG_RTT_CONSOLE=y
CONFIG_UART_CONSOLE=y

# Shell related defines
CONFIG_SHELL=y
CONFIG_KERNEL_SHELL=y
CONFIG_USE_SEGGER_RTT=y
## Disable logs on RTT
CONFIG_SHELL_RTT_INIT_LOG_LEVEL_NONE=y
CONFIG_SHELL_BACKEND_RTT=y
CONFIG_SHELL_BACKEND_SERIAL=n
CONFIG_SHELL_VT100_COMMANDS=y
CONFIG_SHELL_VT100_COLORS=y
CONFIG_SHELL_STACK_SIZE=4096
CONFIG_SHELL_CMD_BUFF_SIZE=128
## Reduce shell memory usage
CONFIG_SHELL_WILDCARD=n
CONFIG_SHELL_HELP_ON_WRONG_ARGUMENT_COUNT=n
CONFIG_SHELL_STATS=n
CONFIG_SHELL_CMDS=n
CONFIG_SHELL_HISTORY=y

# Turn off default shell commands
CONFIG_I2C_SHELL=n
CONFIG_HWINFO_SHELL=n
CONFIG_CLOCK_CONTROL_NRF_SHELL=n
CONFIG_FLASH_SHELL=n
CONFIG_DEVICE_SHELL=n

# Suppress LOG_ERR messages from sd_check_card_type. Because SPI_SDHC has no card presence method,
# assume card is in slot. Thus error message is always shown if card is not inserted
CONFIG_SD_LOG_LEVEL_OFF=y

# Suppress LOG_INF messages from hci_core
CONFIG_BT_HCI_CORE_LOG_LEVEL_WRN=y

Regards,

Omri.

[MahendraTailor]

Hi Omri

Be aware that with LC3 the standard PLC (Packet Loss Concealment) is not good at masking lost pure tone packets.
In fact, use a pure tone (432Hz) to hear packet loss as every single loss can be heard as an audio artifact.

As to why audio degrades when <sic: ACL> connection interval is changed beats me and look forward to how Nordic respond.
Did you mean by any chance the ISO interval - which should be left at 10ms or multiples of it when BN>1?
In fact during a unicast audio, why the need for a 10ms connection interval? A phone is unlikely to even allow you that as even MIDI is only allowed 11.25ms on an iPhone.

[Omri]

I was referring to the ACL connection interval, which is set to 8 (10 ms) by default in the nRF5340 Audio application.

This interval is used from the moment the ACL connection is established until the audio streaming is configured.

Once the streaming is configured and started, the application updates the connection interval to 72 (90 ms).

I noticed that the audio quality is solely dependent on the ACL connection interval at the time the connection is established.

It does not seem to be affected by whether the application performs a connection update later or not.

[Omri]

Hi,

I would like to correct my earlier response.

The audio quality is acceptable only when the ACL connection interval is a multiple of 10ms.

This is why updating the connection interval to 90ms did not impact the audio streaming quality.

Could this be a limitation of NCS v2.8.0?

[Maria Gilje]

Hello Omri,

First I want to apologize for the wait you have had.

Omri said:

The audio quality is acceptable only when the ACL connection interval is a multiple of 10ms.

This is expected as the connection interval is required to be a multiple of the ISO interval. See for example the description for CONFIG_BLE_ACL_CONN_INTERVAL.

Omri said:

This is why updating the connection interval to 90ms did not impact the audio streaming quality.

Could this be a limitation of NCS v2.8.0?

The requirement is also for nRF Connect SDK v2.9.0. That being said, we do recommend starting out projects on the latest tagged release of nRF Connect SDK.

MahendraTailor said:

Be aware that with LC3 the standard PLC (Packet Loss Concealment) is not good at masking lost pure tone packets.
In fact, use a pure tone (432Hz) to hear packet loss as every single loss can be heard as an audio artifact.

This is a good and correct comment from MahendraTailor. I also want to add that the reason for this is that LC3 is designed for music and speech and subjective measurements (perceived quality).

Again, my apologies for the late reply.

Best regards,

Maria