nRF5340 Audio

The nRF5340 Audio application demonstrates audio playback over isochronous channels (ISO) using LC3 or SBC codec compression and decompression, as per Bluetooth LE Audio specifications. It is developed for use with the nRF5340 Audio development kit.

In its default configuration, the application requires access to the non-public external repository containing the LC3 software codec. The application also comes with various tools, including the buildprog.py Python script that simplifies building and programming the firmware.

Overview

The application can work as a gateway or a headset. The gateway receives the audio data from external sources (USB or I2S) and forwards it to one or more headsets. The headset is a receiver device that plays back the audio it gets from the gateway.

Both device types use the same code base, but different firmware, and you need both types of devices for testing the application. Gateways and headsets can both run in one of the available application modes, either the connected isochronous stream (CIS) mode or in the broadcast isochronous stream (BIS) mode. The CIS mode is the default mode of the application.

Changing configuration related to the device type and the application modes requires rebuilding the firmware and reprogramming the development kits.

Regardless of the configuration, the application handles the audio data in the following manner:

  1. The gateway receives audio data from the audio source over USB or I2S.

  2. The gateway processes the audio data in its application core, which channels the data through the application layers:

    1. Audio data is sent to the synchronization module (I2S-based firmware) or directly to the software codec (USB-based firmware).

    2. Audio data is encoded by the software codec.

    3. Encoded audio data is sent to the Bluetooth LE Host.

  3. The host sends the encoded audio data to the LE Audio Controller Subsystem for nRF53 on the network core.

  4. The subsystem forwards the audio data to the hardware radio and sends it to the headset devices, as per the LE Audio specifications.

  5. The headsets receive the encoded audio data on their hardware radio on the network core side.

  6. The LE Audio Controller Subsystem for nRF53 running on each of the headsets sends the encoded audio data to the Bluetooth LE Host on the headsets’ application core.

  7. The headsets process the audio data in their application cores, which channel the data through the application layers:

    1. Audio data is sent to the stream control module and placed in a FIFO buffer.

    2. Audio data is decoded by the software codec either in the synchronization module (I2S-based firmware) or directly (USB-based firmware).

  8. Decoded audio data is sent to the hardware audio output over USB or I2S.

Note

Currently, only a unidirectional stream is supported (gateway to headsets). In addition, only the gateway uses USB. This means that no decoded audio data is sent over USB in the current version.

In the I2S-based firmware for gateway and headsets, sending the audio data through the application layers includes a mandatory synchronization step using the synchronization module. This proprietary module ensures that the audio is played at the same time with the correct speed. For more information, see Synchronization module overview.

Application modes

The application can work either in the connected isochronous stream (CIS) mode or in the broadcast isochronous stream (BIS) mode, depending on the chosen firmware configuration.

CIS and BIS mode overview

CIS and BIS mode overview

Connected Isochronous Stream (CIS)

CIS is a bidirectional communication protocol that allows for sending separate connected audio streams from a source device to one or more receivers. The gateway can send the audio data using both the left and the right ISO channels at the same time, allowing for stereophonic sound reproduction with synchronized playback.

This is the default configuration of the nRF5340 Audio application. In this configuration, you can use the nRF5340 Audio development kit in the role of the gateway, the left headset, or the right headset.

Note

In the current version of the nRF5340 Audio application, the CIS mode offers only monodirectional communication.

Broadcast Isochronous Stream (BIS)

BIS is a monodirectional communication protocol that allows for broadcasting one or more audio streams from a source device to an unlimited number of receivers that are not connected to the source.

In this configuration, you can use the nRF5340 Audio development kit in the role of the gateway or as one of the headsets. Use multiple nRF5340 Audio development kits to test BIS having multiple receiving headsets.

Note

  • In the BIS mode, you can use any number of nRF5340 Audio development kits as receivers.

  • In the current version of the nRF5340 Audio application, the BIS mode offers only monophonic sound reproduction.

The audio quality for both modes does not change, although the processing time for stereo quality can be longer.

Firmware architecture

The following figure illustrates the software layout for the nRF5340 Audio application:

nRF5340 Audio high-level design (overview)

nRF5340 Audio high-level design (overview)

The network core of the nRF5340 SoC runs the LE Audio Controller Subsystem for nRF53. This subsystem is a Bluetooth LE Controller that is custom-made for the application. It is responsible for receiving the audio stream data from hardware layers and forwarding the data to the Bluetooth LE host on the application core. The subsystem implements the lower layers of the Bluetooth Low Energy software stack and follows the LE Audio specification requirements.

The application core runs both the Bluetooth LE Host from Zephyr and the application layer. The application layer is composed of a series of modules from different sources. These modules include the following major ones:

  • Peripheral modules from the nRF Connect SDK:

    • I2S

    • USB

    • SPI

    • TWI/I2C

    • UART (debug)

    • Timer

  • Application-specific custom modules:

    • Stream Control - This module watches over the state machine of the application. It checks the state of the Bluetooth connection, handles button presses and events, receives audio from the host, and forwards the audio data to the next module.

    • FIFO buffers

    • Synchronization module (part of I2S-based firmware for gateway and headsets) - See Synchronization module overview for more information.

  • Application-specific modules from external sources (only one is used at a time):

    • LC3 encoder/decoder (default)

    • SBC encoder/decoder

    Selecting and configuring the right software codec is required to run the application.

Since the application architecture is uniform and the firmware code is shared, the set of audio modules in use depends on the chosen stream mode (BIS or CIS), the chosen audio inputs and outputs (USB or analog jack), and if the gateway or the headset configuration is selected.

Note

In the current version of the application, no bootloader is used, and device firmware update (DFU) is not supported.

USB-based firmware for gateway

The following figure shows an overview of the modules currently included in the firmware that uses USB:

nRF5340 Audio modules on the gateway using USB

nRF5340 Audio modules on the gateway using USB

In this firmware design, no synchronization module is used after decoding the incoming frames or before encoding the outgoing ones. The Bluetooth LE RX FIFO is mainly used to make decoding run in a separate thread.

I2S-based firmware for gateway and headsets

The following figure shows an overview of the modules currently included in the firmware that uses I2S:

nRF5340 Audio modules on the gateway and the headsets using I2S

nRF5340 Audio modules on the gateway and the headsets using I2S

The Bluetooth LE RX FIFO is mainly used to make audio_datapath.c (synchronization module) run in a separate thread. After the encoding, the frames are sent by the encoder thread using a function located in streamctrl.c.

Synchronization module overview

The synchronization module (audio_datapath.c) handles audio synchronization. To synchronize the audio, it executes the following types of adjustments:

  • Presentation compensation

  • Drift compensation

The presentation compensation makes all the headsets play audio at the same time, even if the packets containing the audio frames are not received at the same time on the different headsets. In practice, it moves the audio data blocks in the FIFO forward or backward a few blocks, adding blocks of silence when needed.

The drift compensation adjusts the frequency of the audio clock to adjust the speed at which the audio is played. This is required in the CIS mode, where the gateway and headsets must keep the audio playback synchronized to provide True Wireless Stereo (TWS) audio playback. As such, it provides both larger adjustments at the start and then continuous small adjustments to the audio synchronization. This compensation method counters any drift caused by the differences in the frequencies of the quartz crystal oscillators used in the development kits. Development kits use quartz crystal oscillators to generate a stable clock frequency. However, the frequency of these crystals always slightly differs. The drift compensation makes the inter-IC sound (I2S) interface on the headsets run as fast as the Bluetooth packets reception. This prevents I2S overruns or underruns, both in the CIS mode and the BIS mode.

See the following figure for an overview of the synchronization module.

nRF5340 Audio synchronization module overview

nRF5340 Audio synchronization module overview

Both synchronization methods use the SDU reference timestamps (sdu_ref) as the reference variable. If the device is a gateway that is using I2S as audio source and the stream is unidirectional (gateway to headsets), sdu_ref is continuously being extracted from the LE Audio Controller Subsystem for nRF53 on the gateway. These sdu_ref values are then sent to the gateway’s synchronization module, and used to do drift compensation. This extraction of sdu_ref happens inside the function in streamctrl.c that sends encoded data.

Note

Inside the synchronization module (audio_datapath.c), all time-related variables end with _us (for microseconds). This means that sdu_ref becomes sdu_ref_us inside the module.

As the nRF5340 is a dual-core SoC, and both cores need the same concept of time, each core runs a free-running timer in an infinite loop. These two timers are reset at the same time, and they run from the same clock source. This means that they should always show the same values for the same points in time. The network core of the nRF5340 running the LE controller for nRF53 uses its timer to generate the sdu_ref timestamp for every audio packet received. The application core running the nRF5340 Audio application uses its timer to generate cur_time and frame_start_ts.

After the decoding takes place, the audio data is divided into smaller blocks and added to a FIFO. These blocks are then continuously being fed to I2S, block by block.

See the following figure for the details of the compensation methods of the synchronization module.

nRF5340 Audio's state machine for compensation mechanisms

nRF5340 Audio’s state machine for compensation mechanisms

The following external factors can affect the presentation compensation:

  • The drift compensation must be synchronized to the locked state (DRIFT_STATE_LOCKED) before the presentation compensation can start. This drift compensation adjusts the frequency of the audio clock, indicating that the audio is being played at the right speed. When the drift compensation is not in the locked state, the presentation compensation does not leave the init state (PRES_STATE_INIT). Also, if the drift compensation loses synchronization, moving out of DRIFT_STATE_LOCKED, the presentation compensation moves back to PRES_STATE_INIT.

  • When audio is being played, it is expected that a new audio frame is received in each ISO connection interval. If this does not occur, the headset might have lost its connection with the gateway. When the connection is restored, the application receives an sdu_ref not consecutive with the previously received sdu_ref. Then the presentation compensation is put into PRES_STATE_WAIT to ensure that the audio is still in sync.

Note

When both the drift and presentation compensation are in state locked (DRIFT_STATE_LOCKED and PRES_STATE_LOCKED), LED2 lights up.

Synchronization module flow

The received audio data in the I2S-based firmware devices follows the following path:

  1. The LE Audio Controller Subsystem for nRF53 running on the network core receives the compressed audio data.

  2. The controller subsystem sends the audio data to the Zephyr Bluetooth LE host similarly to the Bluetooth: HCI RPMsg sample.

  3. The host sends the data to the stream control module (streamctrl.c).

  4. The data is sent to a FIFO buffer.

  5. The data is sent from the FIFO buffer to the audio_datapath.c synchronization module. The audio_datapath.c module performs the audio synchronization based on the SDU reference timestamps. Each package sent from the gateway gets a unique SDU reference timestamp. These timestamps are generated on the headset controllers. This enables the creation of True Wireless Stereo (TWS) earbuds where the audio is synchronized in the CIS mode. It does also keep the speed of the inter-IC sound (I2S) interface synchronized with the sending and receiving speed of Bluetooth packets.

  6. The audio_datapath.c module sends the compressed audio data to the LC3 or the SBC audio decoders for decoding.

    Note

    Only the SBC audio codec is open-source. To use the proprietary LC3 audio codec, you need to obtain a license. For more information, see requirements.

  7. The audio decoder decodes the data and sends the uncompressed audio data (PCM) back to the audio_datapath.c module.

  8. The audio_datapath.c module continuously feeds the uncompressed audio data to the hardware codec.

  9. The hardware codec receives the uncompressed audio data over the inter-IC sound (I2S) interface and performs the digital-to-analog (DAC) conversion to an analog audio signal.

Requirements

The nRF5340 Audio application is designed to be used only with the following hardware:

Hardware platforms

PCA

Board name

Build target

nRF5340 Audio DK

PCA10121 revision 1.0.0 or above

nrf5340_audio_dk_nrf5340

nrf5340_audio_dk_nrf5340_cpuapp

Note

The application supports PCA10121 revisions 1.0.0 or above. The application is also compatible with the following pre-launch revisions:

  • Revision 0.7.0 (not recommended).

  • Revisions 0.8.0 and above.

You need at least two nRF5340 Audio development kits (one with the gateway firmware and one with headset firmware) to test the application. For CIS with TWS in mind, three kits are required.

Software codec requirements

The nRF5340 Audio application must use either the LC3 software (developed specifically for use with LE Audio) or the open-source SBC software codec (developed for use with Classic Bluetooth Audio). Each codec requires adding its own repository before building and running.

The default software codec for the application is LC3, which is not open-source. To build the application using this codec requires obtaining access to the LC3 codec repository. To obtain access to the repository, contact the sales department. See Selecting the audio software codec for more information.

nRF5340 Audio development kit

The nRF5340 Audio development kit is a hardware development platform that demonstrates the nRF5340 Audio application.

Key features of the nRF5340 Audio DK

  • Nordic Semiconductor’s nRF5340 Bluetooth LE / multiprotocol SoC.

  • Nordic Semiconductor’s nPM1100 power management SoC.

  • CS47L63 AD-DA converter from Cirrus Logic, dedicated to TWS devices.

  • Stereo analog line input.

  • Mono analog output.

  • Onboard Pulse Density Modulation (PDM) microphone.

  • Computer connection and battery charging through USB-C.

  • Second nRF5340 SoC that works as an onboard SEGGER debugger.

  • SD card reader (no SD card supplied).

  • User-programmable buttons and LEDs.

  • Normal operating temperature range 10–40°C.

  • When using a power adapter to USB, the power supply adapter must meet USB power supply requirements.

  • Embedded battery charge system

  • Rechargeable Li-Po battery with 1500 mAh capacity

Hardware drawings

The nRF5340 Audio hardware drawings show both sides of the development kit in its plastic case:

Figure 1. nRF5340 Audio DK (PCA10121) front view

Figure 1. nRF5340 Audio DK (PCA10121) front view

Figure 2. nRF5340 Audio DK (PCA10121) back view

Figure 2. nRF5340 Audio DK (PCA10121) back view

The following figure shows the back of the development kit without the case:

Figure 3. nRF5340 Audio DK (PCA10121) back view without case

Figure 3. nRF5340 Audio DK (PCA10121) back view without case

For the description of the relevant PCB elements, see the User interface section.

Solder bridge overview

The nRF5340 Audio DK has a range of solder bridges for enabling or disabling selected functionalities. Changes to these are not needed for normal use of the DK. The following table is a complete overview of the solder bridges on the nRF5340 Audio DK.

Designator

Description

Default state

Layer

SB1

Short to connect digital microphone DOUT to P1.06

Open

Top

SB2

Cut to disconnect P0.12 from TRACE

Shorted

Top

SB3

Short to connect PMIC MODE to VOUTB, must not be shorted while SB4 is shorted

Open

Top

SB4

Cut to disable PMIC MODE from GND, must not be shorted while SB3 is shorted

Shorted

Top

SB5

Cut to enable VBAT current measurements on P6

Shorted

Top

SB6

Cut to enable VBAT current measurements on P6

Shorted

Top

SB7

Cut to enable HW CODEC 1.8V current measurements on P8

Shorted

Top

SB8

Cut to enable VDD_nRF current measurements on P9

Shorted

Top

SB9

Cut to disconnect filter from OUTP

Shorted

Top

SB10

Cut to disconnect filter from OUTN

Shorted

Top

SB11

Cut to disconnect the LED for the HW CODEC GPIO

Shorted

Top

SB12

Cut to disconnect digital microphone POWER from the HW CODEC

Shorted

Bottom

SB13

Cut to disconnect digital microphone DATA from the HW CODEC

Shorted

Bottom

SB14

Cut to disconnect digital microphone CLOCK from the HW CODEC

Shorted

Bottom

SB15

Short to connect AUX I2S MCLK to HW CODEC MCLK1

Open

Top

SB16

Short to connect AUX I2S MCLK to HW CODEC MCLK2

Open

Top

SB17

Short to connect P5 pin 6 to GND

Open

Top

SB18

Cut to disconnect P5 pin 6 from SHIELD DETECT

Shorted

Top

SB19

Cut to disconnect RTS and CTS flow control lines on UART1

Shorted

Top

SB20

Cut to disconnect RTS and CTS flow control lines on UART2

Shorted

Top

SB21

Cut to disconnect nRF53 RESET from RESET button when debug is disabled

Shorted

Top

SB22

Short to permanently connect RESET button to nRF53 RESET

Open

Top

SB23

Cut to disconnect RESET button from interface MCU

Shorted

Top

SB24

Short to bypass analog switch for MCLK

Open

Top

Testpoint overview

The following table is a complete overview of the test points on the nRF5340 Audio DK.

Designator

Net

Description

Size

Layer

TP1

NetTP1-1

IN1LP_1 pin of CS47L63

1.5mm

Bottom

TP2

NetTP2-1

IN1LN_1 pin of CS47L63

1.5mm

Bottom

TP3

NetTP3-1

IN1RP pin of CS47L63

1.5mm

Bottom

TP4

NetTP4-1

IN1RN pin of CS47L63

1.5mm

Bottom

TP5

NetTP5-1

IN2LN pin of CS47L63

1.5mm

Bottom

TP6

NetTP6-1

IN2RN pin of CS47L63

1.5mm

Bottom

TP7

HW_CODEC_AUX_I2C.SCL

AUX SCL pin of CS47L63

1.5mm

Top

TP8

HW_CODEC_AUX_I2C.SDA

AUX SDA pin of CS47L63

1.5mm

Top

TP9

P0.07/AIN3

RGB LED 1 Red color input pin

1.5mm

Top

TP10

P0.28/AIN7

RGB LED 2 Red color input pin

1.5mm

Top

TP11

P1.01

LED 3 input pin

1.5mm

Top

TP12

P0.04/AIN0

Button 3

1.5mm

Top

TP13

VDD_EXT_HW_CODEC.1V2

External HW CODEC 1.2V supply

1.5mm

Top

TP14

VDD_EXT_HW_CODEC.1V8

External HW CODEC 1.8V supply

1.5mm

Top

TP15

BAT_NTC

Li-poly battery NTC pin

1.5mm

Top

TP16

BATTERY

Li-poly battery voltage after power switch

1.5mm

Top

TP17

NetC41-1

USB voltage after power switch

1.5mm

Top

TP18

NetC43-2

USB voltage before power switch

1.5mm

Top

TP19

HEADPHONE.OUTP

Headphone jack tip

1.5mm

Top

TP20

HEADPHONE.OUTN

Headphone jack sleeve

1.5mm

Top

TP21

DU_N

USB connector D-

1.5mm

Top

TP22

DU_P

USB connector D+

1.5mm

Top

TP23

SWDIO

nRF5340 Serial Wire Debug data

1.5mm

Top

TP24

SWDCLK

nRF5340 Serial Wire Debug clock

1.5mm

Top

TP25

RESET

nRF5340 Reset

1.5mm

Top

TP26

SD_CS

SD card slot CS line

1.5mm

Top

TP27

SD_SCK

SD card slot SCK line

1.5mm

Top

TP28

VDD_IN_1V

1.2V regulator output

1.5mm

Top

TP29

SUPPLY_1V8

nPM1100 1.8V output

1.5mm

Top

TP30

SUPPLY_3V3

3.3V regulator output

1.5mm

Top

TP31

VDD_DBG_3V3

Debug regulator 3.3V output

1.5mm

Top

TP32

VDD_DBG_1V8

Debug regulator 1.8V output

1.5mm

Top

TP33

SW_EN

Load switch enable signal

1.5mm

Top

TP34

GND

Ground

1.5mm

Top

TP35

GND

Ground

1.5mm

Top

TP36

NetQ9-1

Debug enable signal

1.5mm

Top

TP37

IMCU_SWDIO

Interface MCU Serial Wire Debug data

1.5mm

Top

TP38

IMCU_RESET

Interface MCU Reset

1.5mm

Top

TP39

IMCU_SWDCLK

Interface MCU Serial Wire Debug clock

1.5mm

Top

TP40

SHIELD_DETECT

Detect signal for Arduino compatible shield

1.0mm

Top

TP41

HW_CODEC_IF.SPI.MISO

SPI MISO pin of CS47L63

1.0mm

Top

TP42

HW_CODEC_IF.SPI.MOSI

SPI MOSI pin of CS47L63

1.0mm

Top

TP43

HW_CODEC_IF.SPI.SCK

SPI SCK pin of CS47L63

1.0mm

Top

TP44

HW_CODEC_IF.SPI.CS

SPI SS pin of CS47L63

1.0mm

Top

TP45

HW_CODEC_IF.CTRL.GPIO

GPIO pin of CS47L63

1.0mm

Top

TP46

HW_CODEC_IF.CTRL.IRQ

IRQ pin of CS47L63

1.0mm

Top

TP47

HW_CODEC_IF.CTRL.RESET

RESET pin of CS47L63

1.0mm

Top

TP48

HW_CODEC_IF.I2S.MCLK

MCLK1 pin of CS47L63

1.0mm

Top

TP49

HW_CODEC_IF.I2S.DOUT

I2S DOUT pin of CS47L63

1.0mm

Top

TP50

HW_CODEC_IF.I2S.DIN

I2S DIN pin of CS47L63

1.0mm

Top

TP51

HW_CODEC_IF.I2S.BCLK

I2S BCLK pin of CS47L63

1.0mm

Top

TP52

HW_CODEC_IF.I2S.FSYNC

I2S FSYNC pin of CS47L63

1.0mm

Top

TP53

NetSB12-1

MICBIASB pin of CS47L63

1.0mm

Top

TP54

NetSB13-1

IN1_PDMDATA pin of CS47L63

1.0mm

Top

TP55

NetSB14-1

IN1_PDMCLK pin of CS47L6

1.0mm

Top

TP56

PMIC_ERR

nPM1100 error indication

1.0mm

Top

TP57

PMIC_CHG

nPM1100 charge indication

1.0mm

Top

TP58

P0.29

RGB LED 2 Green color input pin

1.0mm

Top

TP59

P0.30

RGB LED 2 Blue color input pin

1.0mm

Top

TP60

P1.04

UART1 RXD

1.0mm

Top

TP61

P1.05

UART1 TXD

1.0mm

Top

TP62

P1.06

UART1 CTS

1.0mm

Top

TP63

P1.07

UART1 RTS

1.0mm

Top

TP64

NetJ5-10

SD card slot card detect

1.0mm

Top

TP65

P0.11

SD card slot level translator enable

1.0mm

Top

TP66

P1.15

Current shunt monitor alert signal

1.0mm

Top

TP67

GND

Ground

1.5mm

Top

TP68

LINE_IN.LEFT

Line-in jack tip

1.5mm

Top

TP69

LINE_IN.RIGHT

Line-in jack ring

1.5mm

Top

nRF5340 Audio configuration files

The nRF5340 Audio uses combinations of multiple .conf files for different application versions and device types.

The prj.conf file is the main configuration file, and it is always included. The configuration files for specifying application versions and device types are named using the format overlay-<version_or_device>.conf. For example, the configuration file for the release application version is overlay-release.conf.

The following configuration file options are available for the nRF5340 Audio development kit:

  • release - Release version of the application with no debugging features.

  • debug - Debug version of the application. It has the same option settings as the release configuration, but also enables debug options.

  • headset - Application configuration for the headset device type.

  • gateway - Application configuration for the gateway device type.

You can combine the configuration files as follows to obtain one of four different application configurations:

Configuration file/Application configuration

Headset + debug

Gateway + debug

Headset + release

Gateway + release

prj.conf (always used)

overlay-debug.conf

overlay-release.conf

Resulting build directory when using the script

dev_headset/build_debug

dev_gateway/build_debug

dev_headset/build_release

dev_gateway/build_release

This means that when you build the application using the headset device type and the release application version (third column), the build process includes prj.conf, overlay-headset.conf, and overlay-release.conf at the time of building the firmware. If you are building using the script, the build files are then placed in the build/headset_release directory.

See Building and running for detailed information about selecting the desired combination of configuration files for your build.

User interface

The application implements a simple user interface based on the available PCB elements. You can control the application using predefined switches and buttons while the LEDs display information.

Switches

The application uses the following switches on the supported development kit:

Switch

Function

POWER

Turns the development kit on or off.

DEBUG ENABLE

Turns on or off power for debug features. This switch is used for accurate power and current measurements.

Buttons

The application uses the following buttons on the supported development kit:

Button

Function

VOL-

Turns the playback volume down (and unmutes).

VOL+

Turns the playback volume up (and unmutes).

PLAY/PAUSE

Starts or pauses the playback.

BTN 4

During playback, sends a test tone generated by the gateway. Pressing the button multiple times changes the tone frequency. The available values are 1000 Hz, 2000 Hz, and 4000 Hz. Use this tone to check the synchronization of headsets. This button is only supported on the gateway.

BTN 5

Mutes the playback volume.

RESET

Resets the device.

LEDs

To indicate the tasks performed, the application uses the LED behavior described in the following table:

LED

Indication

LED1

Off - No Bluetooth connection.

Blinking blue - Depending on the device and the mode:

  • Headset: Kits have started streaming audio (BIS and CIS modes).

  • Gateway: Kit has connected to a headset (CIS mode) or has started broadcasting audio (BIS mode).

Solid blue - Headset, depending on the mode: Kits have connected to the gateway (CIS mode) or found a broadcasting stream (BIS mode).

LED2

Off - Sync not achieved.

Solid green - Sync achieved (both drift and presentation compensation are in the LOCKED state).

LED3

Blinking green - The nRF5340 Audio DK application core is running.

CODEC

Off - No configuration loaded to the onboard hardware codec.

Solid green - Hardware codec configuration loaded.

RGB1 (bottom side LEDs around the center opening)

Solid green - The device is programmed as the gateway.

Solid blue - The device is programmed as the left headset.

Solid magenta - The device is programmed as the right headset.

Solid yellow - The device is programmed with factory firmware. It must be re-programmed as gateway or headset.

Solid red (debug mode) - Fault in the application core has occurred. See UART log for details and use the RESET button to reset the device. In the release mode, the device resets automatically with no indication on LED or UART.

RGB 2

Controlled by the Bluetooth LE Controller on the network core.

Blinking green - Ongoing CPU activity.

Solid red - Error.

Solid white (all colors on) - The RGB 2 LED is not initialized by the Bluetooth LE Controller.

ERR

PMIC error or a charging error (or both).

CHG

Off - Charge completed or no battery connected.

Solid yellow - Charging in progress.

OB/EXT

Off - No 3.3 V power available.

Solid green - On-board hardware codec selected.

Solid yellow - External hardware codec selected. This LED turns solid yellow also when the devices are reset, for the time then pins are floating.

FTDI SPI

Off - No data is written to the hardware codec using SPI.

Yellow - The same SPI is used for both the hardware codec and the SD card. When this LED is yellow, the shared SPI is used by the FTDI to write data to the hardware codec.

IFMCU (bottom side)

Off - No PC connection available.

Solid green - Connected to PC.

Rapid green flash - USB enumeration failed.

HUB (bottom side)

Off - No PC connection available.

Green - Standard USB hub operation.

Configuration

See Configuring your application for information about how to permanently or temporarily change the configuration.

Setting up the nRF5340 Audio repositories

The application relies on the following external OSS repositories that need to be pulled using west:

  • LC3 software codec repository

  • SBC software codec repository

  • Hardware codec driver repository

To have these repositories managed by west, complete the following steps:

  1. Add the group filter specific to the nRF5340 Audio application to the west manifest file of your project by running the following command:

    west config manifest.group-filter +nrf5340_audio
    
  2. Update west to fetch the repositories in the nRF5340 Audio group:

    west update
    

If west can fetch the repositories correctly, you can now build the application.

For more information about west, see Zephyr’s documentation page.

Selecting the audio software codec

The nRF5340 Audio application must use either the LC3 software (developed specifically for use with LE Audio) or the open-source SBC software codec (developed for use with Classic Bluetooth Audio). Each codec requires adding its own repository before building and running.

The default software codec for the application is LC3, which is not open-source. To build the application using this codec requires obtaining access to the LC3 codec repository. To obtain access to the repository, contact the sales department.

If you decide to use the open-source SBC codec, you also need to change the application’s Kconfig configuration by adding the CONFIG_SW_CODEC_SBC Kconfig option set to y to the main prj.conf file.

Selecting the BIS mode

The CIS mode is the default operating mode for the application. You can switch to the BIS mode by adding the CONFIG_TRANSPORT_BIS Kconfig option set to y to the main prj.conf file.

Selecting the I2S serial

In the default configuration, the gateway application uses the USB serial port as the audio source. The Building and running and Testing steps also refer to using the USB serial connection.

You can switch to using the I2S serial connection by adding the CONFIG_AUDIO_SOURCE_I2S Kconfig option set to y to the main prj.conf file.

When testing the application, an additional audio jack cable is required to use I2S. Use this cable to connect the audio source (PC) to the analog LINE IN on the development kit.

Building and running

This sample can be found under applications/nrf5340_audio in the nRF Connect SDK folder structure.

Note

Building and programming the nRF5340 Audio application is different from the standard procedure of building and programming for the nRF5340 DK. This is because the nRF5340 Audio application only builds and programs the files for the application core. The network core for both gateway and headsets is programmed with the precompiled Bluetooth Low Energy Controller binary file ble5-ctr-rpmsg_<XYZ>.hex, where <XYZ> corresponds to the controller version, for example ble5-ctr-rpmsg_3216.hex. This file includes the LE Audio Controller Subsystem for nRF53 and is provided in the applications/nrf5340_audio/bin directory.

You can build and program the application in one of the following ways:

Prerequisites

Before building the application, make sure to meet the following prerequisites described in the Configuration section:

Testing out of the box

Each development kit comes preprogrammed with basic firmware that indicates if the kit is functional. Before building the application, you can verify if the kit is working by completing the following steps:

  1. Plug the devices into the USB port using USB-C.

  2. Turn on the development kit using the On/Off switch.

  3. Observe RGB1 (bottom side LEDs around the center opening that illuminate the Nordic Semiconductor logo) turn solid yellow, OB/EXT turn solid green, and LED3 start blinking green.

You can now program the development kits with either gateway or headset firmware before they can be used.

Building and programming using script

The suggested method for building the application and programming it to the development kit is running the buildprog.py Python script, which is located in the applications/nrf5340_audio/tools/buildprog directory. The script automates the process of selecting configuration files and building different versions of the application. This eases the process of building and programming images for multiple development kits.

Preparing the JSON file

The script depends on the settings defined in the nrf5340_audio_dk_devices.json file. Before using the script, make sure to update this file with the following information for each development kit you want to use:

  • nrf5340_audio_dk_snr – This field lists the SEGGER serial number. You can check this number on the sticker on the nRF5340 Audio development kit. Alternatively, connect the development kit to your PC and run nrfjprog -i in a command window to print the SEGGER serial number of the kit.

  • nrf5340_audio_dk_dev – This field assigns the specific nRF5340 Audio development kit to be a headset or a gateway.

  • channel – This field is valid only for headsets operating in the CIS mode. It sets the channels on which the headset is meant to work. When no channel is set, the headset is programmed as a left channel one.

Running the script

After editing the nrf5340_audio_dk_devices.json file, run buildprog.py to build the firmware for the development kits. The building command for running the script requires providing the following parameters, in line with nRF5340 Audio configuration files:

  • Core type (-c parameter): app, net, or both

  • Application version (-b parameter): either release or debug

  • Device type (-d parameter): headset, gateway, or both

For example, to build the application using the script for the application core with the debug application version for both the headset and the gateway, run the following command from the buildprog directory:

python buildprog.py -c app -b debug -d both

This command can be ran from any location, as long as the correct path to buildprog.py is given.

The build files are saved in the applications/nrf5340_audio/build directory. The script creates a directory for each application version and device type combination. For example, when running the command above, the script creates the dev_gateway/build_debug and dev_headset/build_debug directories.

Programming with the script

The development kits are programmed according to the serial numbers set in the JSON file. If you run the script with the -p parameter, you can program one or both of the cores after building the files. Make sure to connect the development kits with your PC using USB-C and turn them on using the POWER switch before you run the command. The command for programming can look as follows:

python buildprog.py -c both -b debug -d both -p

This command builds the application with the debug application version for both the headset and the gateway and programs the application core. Given the -c both parameter, it also takes the precompiled Bluetooth Low Energy Controller binary from the applications/nrf5340_audio/bin directory and programs it to the network core of both the gateway and the headset.

Note

If the programming command fails because of Readback protection, run buildprog.py with the --recover-on-fail or -f parameter to recover and re-program automatically when programming fails. For example, using the programming command example above:

python buildprog.py -c both -b debug -d both -p --recover-on-fail
Getting help

Run python buildprog.py -h for information about all available script parameters.

Configuration table overview

When running the script command, a table similar to the following one is displayed to provide an overview of the selected options and parameter values:

+------------+----------+---------+--------------+---------------------+---------------------+
| snr        | snr conn | device  | only reboot  | core app programmed | core net programmed |
+------------+----------+---------+--------------+---------------------+---------------------+
| 1010101010 | True     | headset | Not selected | Selected TBD        | Not selected        |
| 2020202020 | True     | gateway | Not selected | Selected TBD        | Not selected        |
| 3030303030 | True     | headset | Not selected | Selected TBD        | Not selected        |
+------------+----------+---------+--------------+---------------------+---------------------+

See the following table for the meaning of each column and the list of possible values:

Column

Indication

Possible values

snr

Serial number of the device, as provided in the nrf5340_audio_dk_devices.json file.

Serial number.

snr conn

Whether the device with the provided serial number is connected to the PC with a serial connection.

True - Connected.

False - Not connected.

device

Device type, as provided in the nrf5340_audio_dk_devices.json file.

headset - Headset.

gateway - Gateway.

only reboot

Whether the device is to be only reset and not programmed. This depends on the -r parameter in the command, which overrides other parameters.

Not selected - No reset.

Selected TBD - Only reset requested.

Selected done - Reset done.

core app programmed

Whether the application core is to be programmed. This depends on the values provided to the -c and -d parameters (see above).

Not selected - Core won’t be programmed.

Selected TBD - Programming requested.

Selected done - Programming done.

core net programmed

Whether the network core is to be programmed. This depends on the values provided to the -c parameter (see above).

Not selected - Core won’t be programmed.

Selected TBD - Programming requested.

Selected done - Programming done.

Building and programming using command line

You can also build the nRF5340 Audio application using the standard nRF Connect SDK build steps for the command line.

Note

Using this method requires you to build and progam each development kit one at a time before moving to the next configuration, which can be time-consuming. Building and programming using script is recommended.

Building the application

Complete the following steps to build the application:

  1. Choose the combination of the build flags, in line with nRF5340 Audio configuration files:

    1. Choose the application version by using one of the following options:

      • -DOVERLAY_CONFIG=overlay-debug.conf

      • -DOVERLAY_CONFIG=overlay-release.conf

    2. Choose the device type by using one of the following options:

      • -DOVERLAY_CONFIG=overlay-headset.conf

      • -DOVERLAY_CONFIG=overlay-gateway.conf

    Both build flags must be provided using only one -DOVERLAY_CONFIG parameter, as shown in the following step.

  2. Build the application using the standard build steps. For example, if you want to build the firmware for the application core as a headset using the debug application version, you can run the following command:

    west build -b nrf5340_audio_dk_nrf5340_cpuapp --pristine -- -DOVERLAY_CONFIG="overlay-headset.conf overlay-debug.conf"
    

    Unlike when Building and programming using script, this command creates the build files directly in the build directory. This means that you first need to program the development kit for the headset before you build and program other development kits.

Programming the application

After building the files for the development kit you want to program, complete the following steps to program the application from the command line:

  1. Plug the device into the USB port using USB-C.

  2. Turn on the development kit using the On/Off switch.

  3. Open a command prompt.

  4. Run the following command to print the SEGGER serial number of your development kit:

    nrfjprog -i
    

    Note

    Pay attention to which device is to be programmed with the gateway HEX file and which devices are to be programmed with the headset HEX file.

  5. Program the network core on the development kit by running the following command:

    nrfjprog --program bin/ble5-ctr-rpmsg_3216.hex --chiperase --coprocessor CP_NETWORK -r
    

    The network core for both gateway and headsets is programmed with the precompiled Bluetooth Low Energy Controller binary file ble5-ctr-rpmsg_<XYZ>.hex, where <XYZ> corresponds to the controller version, for example ble5-ctr-rpmsg_3216.hex. This file includes the LE Audio Controller Subsystem for nRF53 and is provided in the applications/nrf5340_audio/bin directory.

  6. Program the application core on the development kit with the respective HEX file from the build directory by running the following command:

    nrfjprog --program build/zephyr/zephyr.hex --coprocessor CP_APPLICATION --sectorerase -r
    

    In this example, build/zephyr/zephyr.hex is the HEX binary file for the application core.

  7. If any device is not programmed due to Readback protection, complete the following steps:

    1. Run the following commands to recover the device:

      nrfjprog --recover --coprocessor CP_NETWORK
      nrfjprog --recover
      
    2. Repeat steps 5 and 6 to program both cores again.

  8. When using the default CIS configuration, if you want to use two headset devices, you must also populate the UICR with the desired channel for each headset. Use the following commands, depending on which headset you want to populate:

    • Left headset:

      nrfjprog --memwr 0x00FF80F4 --val 0
      
    • Right headset:

      nrfjprog --memwr 0x00FF80F4 --val 1
      

    Select the correct board when prompted with the popup or add the --snr parameter followed by the SEGGER serial number of the correct board at the end of the nrfjprog command.

Testing

After building and programming the application, you can test it for both the CIS and the BIS modes. The following testing scenarios assume you are using USB as the audio source on the gateway. This is the default setting.

Testing the default CIS mode

Complete the following steps to test the CIS mode for one gateway and two headset devices:

  1. Make sure that the development kits are still plugged into the USB port using USB-C and are turned on. After programming, RGB2 starts blinking green on every device to indicate the ongoing CPU activity on the network core. LED3 starts blinking green on every device to indicate the ongoing CPU activity on the application core.

  2. Wait for the LED1 on the gateway to start blinking blue. This happens shortly after programming the development kit and indicates that the gateway device is connected to at least one headset and ready to send data.

  3. Search the list of audio devices listed in the sound settings of your operating system for nRF5340 USB Audio (gateway) and select it as the output device.

  4. Connect headphones to the HEADPHONE audio jack on both headset devices.

  5. Start audio playback on your PC from any source.

  6. After LED1 turns solid blue on the headsets and starts blinking blue on the gateway, press the PLAY/PAUSE button on a headset. LED1 starts blinking blue and the audio stream starts on the chosen headset.

    Note

    The audio outputs only to the left channel of the audio jack, even if the given headset is configured as the right headset. This is because of the mono hardware codec chip used on the development kits. If you want to play stereo sound using one development kit, you must connect an external hardware codec chip that supports stereo.

  7. Wait for the LED2 to light up solid green to indicate that the audio synchronization is achieved between the gateway and the chosen headset.

  8. Press the PLAY/PAUSE button on the second headset. Both LED1 and LED2 have the same behavior as for the first headset.

  9. Press the VOL+ button on one of the headsets. The playback volume increases for both headsets.

  10. Press the VOL- button on the gateway. The playback volume decreases for both headsets.

  11. Press the PLAY/PAUSE button on one of the headsets. The playback stops for the given headset and continues on the other one.

  12. Press the RESET button on the gateway. The gateway resets and the playback on the unpaused headset stops. After some time, the gateway establishes the connection with both headsets and resumes the playback on the unpaused headset.

  13. Press the PLAY/PAUSE button on one of the paused headsets. The playback resumes in sync with the other headset.

  14. Press the BTN 4 button on the gateway multiple times. For each button press, the audio stream playback is stopped and the gateway sends a test tone to both headsets. These tones can be used as audio cues to check the synchronization of the headsets.

When you finish testing, power off the nRF5340 Audio development kits by switching the power switch from On to Off.

Testing the BIS mode

Testing the BIS mode is identical to Testing the default CIS mode, except for the following differences:

  • You must select the BIS mode manually before building the application.

  • You can play the audio stream with different audio settings on the receivers. For example, you can decrease or increase the volume separately for each receiver during playback.

Adapting application for end products

This section describes the relevant configuration sources and lists the steps required for adapting the nRF5340 Audio application to end products.

Board configuration sources

The nRF5340 Audio application uses the following files as board configuration sources:

  • Devicetree Specification (DTS) files - These reflect the hardware configuration. See Devicetree for more information about the DTS data structure.

  • Kconfig files - These reflect the hardware-related software configuration. See Kconfig - Tips and Best Practices for information about how to configure them.

  • Memory layout configuration files - These define the memory layout of the application.

You can see the nrf/boards/arm/nrf5340_audio_dk_nrf5340 directory as an example of how these files are structured.

For information about differences between DTS and Kconfig, see Devicetree versus Kconfig. For detailed instructions for adding Zephyr support to a custom board, see Zephyr’s Board Porting Guide.

Application configuration sources

The application configuration source files define the set of options used by the nRF5340 Audio application board and the included modules (such as Bluetooth or I2S). These are .conf files that modify the default Kconfig values defined in the Kconfig files.

The following .conf files are the default ones in the application:

  • The prj.conf application configuration file.

  • Either overlay-debug.conf or overlay-release.conf.

  • Either overlay-gateway.conf or overlay-headset.conf.

You need to edit these files if you want to add new functionalities to your application, but editing these files when adding a new board is not required.

Adding a new board

Note

The first three steps of the configuration procedure are identical to the steps described in Zephyr’s Board Porting Guide.

To use the nRF5340 Audio application with your custom board:

  1. Define the board files for your custom board:

    1. Create a new directory in the nrf/boards/arm/ directory with the name of the new board.

    2. Copy the nRF5340 Audio board files from the nrf5340_audio_dk_nrf5340 directory located in the nrf/boards/arm/ folder to the newly created directory.

  2. Edit the DTS files to make sure they match the hardware configuration. Pay attention to the following elements:

    • Pins that are used.

    • Interrupt priority that might be different.

  3. Edit the board’s Kconfig files to make sure they match the required system configuration. For example, disable the drivers that will not be used by your device.

  4. Build the application by selecting the name of the new board (for example, new_audio_board_name) in your build system. For example, when building from the command line, add -b new_audio_board_name to your build command.

Dependencies

This application uses the following nrfx libraries:

  • nrfx_clock.h

  • nrfx_gpiote.h

  • nrfx_timer.h

  • nrfx_dppi.h

  • nrfx_i2s.h

  • nrfx_ipc.h

  • nrfx_nvmc.h

The application also depends on the following Zephyr libraries:

Application configuration options

CONFIG_NRF5340_AUDIO

(bool) nRF5340 Audio [EXPERIMENTAL]

None

CONFIG_AUDIO_DEV

(int) Select which device type to compile for. 1=HEADSET or 2=GATEWAY

Setting this variable to 1 selects that the project is compiled as a HEADSET device. Setting to 2 will compile as a GATEWAY.

CONFIG_TRANSPORT_BIS

(bool) Use BIS (Broadcast Isochronous Stream)

None

CONFIG_TRANSPORT_CIS

(bool) Use CIS (Connected Isochronous Stream)

None

CONFIG_AUDIO_FRAME_DURATION_7_5_MS

(bool) Frame duration 7.5 ms

None

CONFIG_AUDIO_FRAME_DURATION_10_MS

(bool) Frame duration 10 ms

None

CONFIG_AUDIO_FRAME_DURATION_US

(int)

Audio frame duration in µs

CONFIG_AUDIO_SAMPLE_RATE_HZ

(int) Sample rate Hz

For now 48 kHz is the only sample rate supported

CONFIG_AUDIO_BIT_DEPTH_16

(bool) 16 bit audio

None

CONFIG_AUDIO_BIT_DEPTH_24

(bool) 24 bit audio

Setting a 24 bit depth for I2S leads to a mismatch between requested MCK and actual MCK. Even though requested LRCLK is 48 kHz, actual LRCLK might be 42 kHz or 51 kHz, depending on ratio and ACLK settings

CONFIG_AUDIO_BIT_DEPTH_32

(bool) 32 bit audio

None

CONFIG_AUDIO_BIT_DEPTH_BITS

(int)

Bit depth of one sample in storage. Note that 24 bit depth requires 32 bit for storage

CONFIG_AUDIO_BIT_DEPTH_OCTETS

(int)

Bit depth of one sample in storage given in octets. Note that 24 bit depth requires 4 octets for storage

CONFIG_AUDIO_SOURCE_USB

(bool) Use USB as audio source

Set USB as audio source. Note that this forces the stream to be unidirectional because of CPU load

CONFIG_AUDIO_SOURCE_I2S

(bool) Use I2S as audio source

None

CONFIG_AUDIO_HEADSET_CHANNEL_RUNTIME

(bool) Select at runtime

Make channel selection at runtime. Selected value is stored in persistent memory. Left channel: Hold volume-down button on headset while resetting headset. Right channel: Hold volume-up button on headset while resetting headset.

CONFIG_AUDIO_HEADSET_CHANNEL_COMPILE_TIME

(bool) Set at compile-time

Set channel selection at compile-time.

CONFIG_AUDIO_HEADSET_CHANNEL

(int) Audio channel used by headset

Audio channel compile-time selection. Left = 0. Right = 1.

CONFIG_SW_CODEC_LC3

(bool) LC3

LC3 is the mandatory codec for LE Audio

CONFIG_SW_CODEC_SBC

(bool) SBC

Subband Codec

CONFIG_SW_CODEC_PLC_DISABLED

(bool) Skip PLC on a bad frame and fill the output buffer(s) with zeros instead

None

CONFIG_LC3_MONO_BITRATE

(int) Bitrate for LC3

None

CONFIG_SBC_NUM_FRAMES_PER_BLE_PACKET

(int) Number of packets be transmitted in one connection interval

For the current SBC codec default setting, it is possible to send 5 SBC encoded frames in a 10 ms connection interval since a SBC frame is 2 ms internally.

CONFIG_SBC_NO_OF_BLOCKS

(int) Number of blocks (4, 8, 12, 16)

None

CONFIG_SBC_NO_OF_SUBBANDS

(int) Number of subbands (4, 8)

None

CONFIG_SBC_BITPOOL

(int) Bitpool value

Bitpool determines the size of each encoded frame. Size of frame = 4 + (blocks * bitpool + 4 * subbands) / 8 Frame rate = Sampling rate / (blocks * subbands) Bitrate = size of frame * frame rate

CONFIG_SBC_BIT_ALLOC_METHOD

(int) Bit allocation Method (0 -> Loudness, 1 -> SNR)

None

CONFIG_SBC_CHANNEL_MODE_MONO

(int) Channel Mode Mono (0->Mono)

Only mono is supported at the moment

CONFIG_BUF_BLE_RX_PACKET_NUM

(int)

Value can be adjusted to affect the overall latency. This adjusts the number packets in the BLE FIFO RX buffer, which is where the main latency resides. A low value will decrease latency and reduce stability, and vice-versa. Two is recommended minimum to reduce the likelyhood of audio gaps due to BLE retransmits.

CONFIG_STREAM_BIDIRECTIONAL

(bool) Enable bi-directional stream - Currently not supported

Bi-directional stream enables encoder and decoder on both sides, and one device can both send and receive audio.

CONFIG_LOG_AUDIO_CODEC_LEVEL

(int) Log level for streamctrl

None

CONFIG_LOG_STREAMCTRL_LEVEL

(int) Log level for streamctrl

None

CONFIG_LOG_AUDIO_DATAPATH_LEVEL

(int) Log level for audio_datapath

None

CONFIG_LOG_AUDIO_SYNC_TIMER_LEVEL

(int) Log level for audio_sync_timer

None

CONFIG_ENCODER_THREAD_PRIO

(int) Priority for encoder thread

This is a preemptible thread

CONFIG_AUDIO_DATAPATH_THREAD_PRIO

(int) Priority for audio datapath thread

This is a preemptible thread

CONFIG_ENCODER_STACK_SIZE

(int) Stack size for encoder thread

None

CONFIG_AUDIO_DATAPATH_STACK_SIZE

(int) Stack size for audio datapath thread

None

CONFIG_BLE_ACL_CONN_INTERVAL

(int) BLE ACL Connection Interval (x*1.25ms)

None

CONFIG_BLE_ACL_SLAVE_LATENCY

(int) BLE Slave Latency

None

CONFIG_BLE_ACL_SUP_TIMEOUT

(int) BLE Supervision Timeout (x*10ms)

None

CONFIG_BLE_LE_POWER_CONTROL_ENABLED

(bool) Enable LE power control feature

The LE power control feature makes devices be able to change TX power dynamically and automatically during connection, which provides effective communication.

CONFIG_BLE_CONN_TX_POWER_0DBM

(bool) 0dBm

None

CONFIG_BLE_CONN_TX_POWER_NEG_1DBM

(bool) -1dBm

None

CONFIG_BLE_CONN_TX_POWER_NEG_2DBM

(bool) -2dBm

None

CONFIG_BLE_CONN_TX_POWER_NEG_3DBM

(bool) -3dBm

None

CONFIG_BLE_CONN_TX_POWER_NEG_4DBM

(bool) -4dBm

None

CONFIG_BLE_CONN_TX_POWER_NEG_5DBM

(bool) -5dBm

None

CONFIG_BLE_CONN_TX_POWER_NEG_6DBM

(bool) -6dBm

None

CONFIG_BLE_CONN_TX_POWER_NEG_7DBM

(bool) -7dBm

None

CONFIG_BLE_CONN_TX_POWER_NEG_8DBM

(bool) -8dBm

None

CONFIG_BLE_CONN_TX_POWER_NEG_12DBM

(bool) -12dBm

None

CONFIG_BLE_CONN_TX_POWER_NEG_16DBM

(bool) -14dBm

None

CONFIG_BLE_CONN_TX_POWER_NEG_20DBM

(bool) -20dBm

None

CONFIG_BLE_CONN_TX_POWER_NEG_40DBM

(bool) -40dBm

None

CONFIG_BLE_CONN_TX_POWER_DBM

(int)

None

CONFIG_BLE_ADV_TX_POWER_0DBM

(bool) 0dBm

None

CONFIG_BLE_ADV_TX_POWER_NEG_1DBM

(bool) -1dBm

None

CONFIG_BLE_ADV_TX_POWER_NEG_2DBM

(bool) -2dBm

None

CONFIG_BLE_ADV_TX_POWER_NEG_3DBM

(bool) -3dBm

None

CONFIG_BLE_ADV_TX_POWER_NEG_4DBM

(bool) -4dBm

None

CONFIG_BLE_ADV_TX_POWER_NEG_5DBM

(bool) -5dBm

None

CONFIG_BLE_ADV_TX_POWER_NEG_6DBM

(bool) -6dBm

None

CONFIG_BLE_ADV_TX_POWER_NEG_7DBM

(bool) -7dBm

None

CONFIG_BLE_ADV_TX_POWER_NEG_8DBM

(bool) -8dBm

None

CONFIG_BLE_ADV_TX_POWER_NEG_12DBM

(bool) -12dBm

None

CONFIG_BLE_ADV_TX_POWER_NEG_16DBM

(bool) -14dBm

None

CONFIG_BLE_ADV_TX_POWER_NEG_20DBM

(bool) -20dBm

None

CONFIG_BLE_ADV_TX_POWER_NEG_40DBM

(bool) -40dBm

None

CONFIG_BLE_ADV_TX_POWER_DBM

(int)

None

CONFIG_BLE_DEVICE_NAME_BASE

(string)

Base for the device name that will be visible over the air. The actual name on air could look like: NRF5340_AUDIO_DEV_H_L or NRF5340_AUDIO_DEV_H_R depending on which device it is.

CONFIG_BLE_ISO_TEST_PATTERN

(bool) Transmit a test pattern to measure link performance

This will transmit the same amount of data as an audio stream, but the data will be an incrementing value ranging from 0-255 and repeating. Note that enabling this feature will disable the audio stream.

CONFIG_BLE_ISO_RX_STATS_S

(int) Interval in seconds to print BLE ISO RX stats. 0 to deactivate

None

CONFIG_LOG_BLE_LEVEL

(int) Log level for Bluetooth related files

None

CONFIG_CS47L63_THREAD_PRIO

(int) Priority for CS47L63 thread

This is a preemptible thread

CONFIG_CS47L63_STACK_SIZE

(int) Stack size for CS47L63

None

CONFIG_LOG_CTRL_EVENTS_LEVEL

(int) Log level for ctrl_events.c

None

CONFIG_BUTTON_DEBOUNCE_MS

(int) Button debounce time in ms

None

CONFIG_POWER_MODULE_MIN_MEAS_TIME_MS

(int) Power measurement interval in milliseconds

None

CONFIG_POWER_MODULE_MEAS_START_ON_BOOT

(bool) Start power measurements for all rails on boot

This option will automatically start and periodically print the voltage, current consumption, and power usage for the following rails: VBAT, VDD1_CODEC, VDD2_CODEC, and VDD2_NRF

CONFIG_I2S_LRCK_FREQ_HZ

(int)

The sample rate of I2S. For now this is tied directly to AUDIO_SAMPLE_RATE_HZ Note that this setting is only valid in I2S master mode.

CONFIG_I2S_CH_NUM

(int)

The I2S driver itself supports both mono and stereo. Parts of the implementation are configured for only stereo.

CONFIG_LOG_I2S_LEVEL

(int) Log level for audio_i2s

None

CONFIG_LOG_LED_LEVEL

(int) Log level for LED

None

CONFIG_LOG_AUDIO_USB_LEVEL

(int) Log level for USB audio

None

CONFIG_LOG_POWER_MODULE_LEVEL

(int) Log level for power module

None

CONFIG_LOG_PMIC_LEVEL

(int) Log level for PMIC

None

CONFIG_LOG_HW_CODEC_LEVEL

(int) Log level for HW_CODEC

None

CONFIG_LOG_BUTTON_HANDLER_LEVEL

(int) Log level for button_handler.c

None

CONFIG_LOG_SD_CARD_LEVEL

(int) Log level for SD card

None

CONFIG_POWER_MODULE_THREAD_PRIO

(int) Priority for power measurement thread

This is a preemptible thread

CONFIG_POWER_MODULE_STACK_SIZE

(int) Stack size for power module

None

CONFIG_FIFO_FRAME_SPLIT_NUM

(int) Number of blocks to make up one frame of audio data

Easy DMA in I2S requires two buffers to be filled before I2S transmission will begin. In order to reduce latency, an audio frame can be split into multiple blocks with this parameter. USB sends data in 1 ms blocks, so we need the split to match that. Since we set frame size to 10 ms for USB, 10 is selected as FRAME_SPLIT_NUM

CONFIG_FIFO_TX_FRAME_COUNT

(int) Max number of audio frames in TX slab

FIFO_TX is the buffer that holds decoded audio data before it is sent to either I2S or USB

CONFIG_FIFO_RX_FRAME_COUNT

(int) Max number of audio frames in RX slab

FIFO_RX is the buffer that holds uncompressed audio data coming from either I2S or USB

CONFIG_LOG_BOARD_VERSION_LEVEL

(int) Log level for the board/HW version

None

CONFIG_LOG_CS47L63_LEVEL

(int) Log level for CS47L63

None

CONFIG_LOG_MAIN_LEVEL

(int) Log level for main file

None

CONFIG_PRINT_STACK_USAGE_MS

(int) Print stack usage every x milliseconds

None