Puretone Headset
Description
The Puretone Headset application is an audio example based on the SPARK PureTone Headset . It uses the SPARK Wireless Core to transmit a stereo audio stream with 96kHz/24-bit depth from the Coordinator to the Node (the Main Channel), and conversely, a mono audio stream with 48kHz/16-bit depth from the Node back to the Coordinator (the Back Channel). When the link quality degrades, it will automatically switch to fallback mode which involves multiple fallback processing stages on both sides. The audio stream will revert to default once the link quality returns to normal.
The application can either use the analog audio codec of the EVKs or the USB audio interface to receive and transmit audio data. Different compilation flags are required to select the desired audio interface. A USB audio Coordinator can communicate with an analog audio Node and vice versa.
To compile the application for USB audio, set the “USB_AUDIO_ENABLED”: “ON” flag in the application’s CMake preset cacheVariables section.
{ "name": "puretone-headset-sr11xx-quasar-usb_audio", "inherits": ["base","quasar"], "description": "Puretone Headset example for SR11xx with Quasar USB AUDIO", "cacheVariables": { "APP": "Puretone-Headset", "TRANSCEIVER": "SR1100", "USB_AUDIO_ENABLED": "ON" } },
Note
This application supports only SR1120 transceiver operating with the Quasar platform.
Behavior
Audio Configuration
The application can be configured using the sac_cfg.h file located in the config folder.
/* **** Main Channel Settings. **** */
#define MAIN_CHANNEL_SAMPLE_RATE_HZ 96000
#define MAIN_CHANNEL_SAMPLE_COUNT 40
#define MAIN_CHANNEL_CHANNEL_COUNT 2
#define MAIN_CHANNEL_SAMPLE_RATE_HZ 96000
#define MAIN_CHANNEL_CHANNEL_COUNT 2
#define MAIN_CHANNEL_BIT_DEPTH 24
/* Maximum Latency. */
#define MAIN_CHANNEL_MAX_LATENCY_MS 15
/* Fallback modes Latency. */
#define MAIN_CHANNEL_FBK_0_LATENCY_MS 5
#define MAIN_CHANNEL_FBK_1_LATENCY_MS 7
#define MAIN_CHANNEL_FBK_2_LATENCY_MS 10
#define MAIN_CHANNEL_FBK_3_LATENCY_MS 15
/* Fallback modes sample count. */
#define MAIN_CHANNEL_FBK_0_SAMPLE_COUNT 40
#define MAIN_CHANNEL_FBK_1_SAMPLE_COUNT 34
#define MAIN_CHANNEL_FBK_2_SAMPLE_COUNT 34
#define MAIN_CHANNEL_FBK_3_SAMPLE_COUNT 46
/* A header is added to audio samples during fallback. */
#define MAIN_CHANNEL_FALLBACK_HEADER_SIZE sizeof(sac_header_t)
/* A header is added to compressed audio samples during fallback. */
#define MAIN_CHANNEL_FALLBACK_COMPRESSION_HEADER_SIZE \
(sizeof(sac_header_t) + SAC_COMPRESSION_HEADER_SIZE(MAIN_CHANNEL_CHANNEL_COUNT))
/* Calculated values. */
#define MAIN_CHANNEL_SWC_PAYLOAD_SIZE \
SAC_CALCULATE_PAYLOAD_SIZE(MAIN_CHANNEL_SAMPLE_COUNT, MAIN_CHANNEL_CHANNEL_COUNT, MAIN_CHANNEL_BIT_DEPTH)
#define MAIN_CHANNEL_I2S_PAYLOAD_SIZE \
SAC_CALCULATE_PAYLOAD_SIZE(MAIN_CHANNEL_SAMPLE_COUNT, MAIN_CHANNEL_CHANNEL_COUNT, I2S_DMA_BIT_DEPTH)
/* Size of the latency queue used by the Audio Core for the main channel. */
#define MAIN_CHANNEL_LATENCY_QUEUE_SIZE \
SAC_CALCULATE_LATENCY_QUEUE_SIZE(MAIN_CHANNEL_MAX_LATENCY_MS, CODEC_LATENCY_MS, MAIN_CHANNEL_SAMPLE_COUNT, \
MAIN_CHANNEL_SAMPLE_RATE_HZ)
#define MAIN_CHANNEL_FBK_0_LATENCY_QUEUE_SIZE \
SAC_CALCULATE_LATENCY_QUEUE_SIZE(MAIN_CHANNEL_FBK_0_LATENCY_MS, CODEC_LATENCY_MS, MAIN_CHANNEL_SAMPLE_COUNT, \
MAIN_CHANNEL_SAMPLE_RATE_HZ)
#define MAIN_CHANNEL_FBK_1_LATENCY_QUEUE_SIZE \
SAC_CALCULATE_LATENCY_QUEUE_SIZE(MAIN_CHANNEL_FBK_1_LATENCY_MS, CODEC_LATENCY_MS, MAIN_CHANNEL_SAMPLE_COUNT, \
MAIN_CHANNEL_SAMPLE_RATE_HZ)
#define MAIN_CHANNEL_FBK_2_LATENCY_QUEUE_SIZE \
SAC_CALCULATE_LATENCY_QUEUE_SIZE(MAIN_CHANNEL_FBK_2_LATENCY_MS, CODEC_LATENCY_MS, MAIN_CHANNEL_SAMPLE_COUNT, \
MAIN_CHANNEL_SAMPLE_RATE_HZ)
#define MAIN_CHANNEL_FBK_3_LATENCY_QUEUE_SIZE \
SAC_CALCULATE_LATENCY_QUEUE_SIZE(MAIN_CHANNEL_FBK_3_LATENCY_MS, CODEC_LATENCY_MS, MAIN_CHANNEL_SAMPLE_COUNT, \
MAIN_CHANNEL_SAMPLE_RATE_HZ)
/* Fallback modes payload size. */
#define MAIN_CHANNEL_FALLBACK_PAYLOAD_SIZE \
{ \
SAC_CALCULATE_PAYLOAD_SIZE(MAIN_CHANNEL_FBK_1_SAMPLE_COUNT, MAIN_CHANNEL_CHANNEL_COUNT, 24) + \
MAIN_CHANNEL_FALLBACK_HEADER_SIZE, \
SAC_CALCULATE_PAYLOAD_SIZE(MAIN_CHANNEL_FBK_2_SAMPLE_COUNT, MAIN_CHANNEL_CHANNEL_COUNT, 16) + \
MAIN_CHANNEL_FALLBACK_HEADER_SIZE, \
SAC_CALCULATE_PAYLOAD_SIZE(MAIN_CHANNEL_FBK_3_SAMPLE_COUNT, MAIN_CHANNEL_CHANNEL_COUNT, \
SAC_COMPRESSION_SAMPLE_RESOLUTION) + \
MAIN_CHANNEL_FALLBACK_COMPRESSION_HEADER_SIZE, \
}
/* Accumulator settings. */
#define MAIN_CHANNEL_MAX_ACC_MUL 23
#define MAIN_CHANNEL_MAX_ACC_DIV 10
#define MAIN_CHANNEL_ACC_MUL \
{ \
1, \
17, \
17, \
23, \
}
#define MAIN_CHANNEL_ACC_DIV \
{ \
1, \
10, \
10, \
10, \
}
/* Fallback latency. */
#define MAIN_CHANNEL_FALLBACK_LATENCY_QUEUE_SIZE \
{ \
MAIN_CHANNEL_FBK_0_LATENCY_QUEUE_SIZE, \
MAIN_CHANNEL_FBK_1_LATENCY_QUEUE_SIZE, \
MAIN_CHANNEL_FBK_2_LATENCY_QUEUE_SIZE, \
MAIN_CHANNEL_FBK_3_LATENCY_QUEUE_SIZE, \
}
/* Fallback latency fifo size. */
#define MAIN_CHANNEL_FALLBACK_LATENCY_FIFO_SIZE \
{ \
(MAIN_CHANNEL_FBK_0_LATENCY_QUEUE_SIZE * ((MAIN_CHANNEL_BIT_DEPTH + 7) / SAC_BYTE_SIZE_BITS)), \
(MAIN_CHANNEL_FBK_1_LATENCY_QUEUE_SIZE * ((MAIN_CHANNEL_BIT_DEPTH + 7) / SAC_BYTE_SIZE_BITS)), \
(MAIN_CHANNEL_FBK_2_LATENCY_QUEUE_SIZE * ((MAIN_CHANNEL_BIT_DEPTH + 7) / SAC_BYTE_SIZE_BITS)), \
(MAIN_CHANNEL_FBK_3_LATENCY_QUEUE_SIZE * ((MAIN_CHANNEL_BIT_DEPTH + 7) / SAC_BYTE_SIZE_BITS)), \
}
/* **** Back Channel Settings. **** */
#define BACK_CHANNEL_SAMPLE_RATE_HZ 48000
#define BACK_CHANNEL_SAMPLE_COUNT 68
#define BACK_CHANNEL_CHANNEL_COUNT 1
#define BACK_CHANNEL_BIT_DEPTH 16
/* Maximum Latency. */
#define BACK_CHANNEL_MAX_LATENCY_MS 15
/* Fallback modes Latency. */
#define BACK_CHANNEL_FBK_0_LATENCY_MS 10
#define BACK_CHANNEL_FBK_1_LATENCY_MS 15
/* Fallback mode sample count. */
#define BACK_CHANNEL_FBK_1_SAMPLE_COUNT 120
/* A header is added to compressed audio samples during fallback. */
#define BACK_CHANNEL_FALLBACK_COMPRESSION_HEADER_SIZE \
(sizeof(sac_header_t) + SAC_COMPRESSION_HEADER_SIZE(BACK_CHANNEL_CHANNEL_COUNT))
/* Calculated values. */
#define BACK_CHANNEL_SWC_PAYLOAD_SIZE \
SAC_CALCULATE_PAYLOAD_SIZE(BACK_CHANNEL_SAMPLE_COUNT, BACK_CHANNEL_CHANNEL_COUNT, BACK_CHANNEL_BIT_DEPTH)
#define BACK_CHANNEL_I2S_SAMPLE_COUNT ((BACK_CHANNEL_SAMPLE_COUNT * I2S_SAMPLE_RATE_HZ) / BACK_CHANNEL_SAMPLE_RATE_HZ)
#define BACK_CHANNEL_I2S_PAYLOAD_SIZE \
SAC_CALCULATE_PAYLOAD_SIZE(BACK_CHANNEL_I2S_SAMPLE_COUNT, BACK_CHANNEL_CHANNEL_COUNT, I2S_DMA_BIT_DEPTH)
/* Size of the latency queue used by the Audio Core for the back channel. */
#define BACK_CHANNEL_LATENCY_QUEUE_SIZE \
SAC_CALCULATE_LATENCY_QUEUE_SIZE(BACK_CHANNEL_MAX_LATENCY_MS, CODEC_LATENCY_MS, BACK_CHANNEL_SAMPLE_COUNT, \
BACK_CHANNEL_SAMPLE_RATE_HZ)
#define BACK_CHANNEL_FBK_0_LATENCY_QUEUE_SIZE \
SAC_CALCULATE_LATENCY_QUEUE_SIZE(BACK_CHANNEL_FBK_0_LATENCY_MS, CODEC_LATENCY_MS, BACK_CHANNEL_SAMPLE_COUNT, \
BACK_CHANNEL_SAMPLE_RATE_HZ)
#define BACK_CHANNEL_FBK_1_LATENCY_QUEUE_SIZE \
SAC_CALCULATE_LATENCY_QUEUE_SIZE(BACK_CHANNEL_FBK_1_LATENCY_MS, CODEC_LATENCY_MS, BACK_CHANNEL_SAMPLE_COUNT, \
BACK_CHANNEL_SAMPLE_RATE_HZ)
/* Fallback modes payload size. */
#define BACK_CHANNEL_FALLBACK_PAYLOAD_SIZE \
(SAC_CALCULATE_PAYLOAD_SIZE(BACK_CHANNEL_FBK_1_SAMPLE_COUNT, BACK_CHANNEL_CHANNEL_COUNT, \
SAC_COMPRESSION_SAMPLE_RESOLUTION) + \
BACK_CHANNEL_FALLBACK_COMPRESSION_HEADER_SIZE)
/* Accumulator settings. */
#define BACK_CHANNEL_MAX_ACC_MUL 30
#define BACK_CHANNEL_MAX_ACC_DIV 17
#define BACK_CHANNEL_ACC_MUL \
{ \
1, \
30, \
}
#define BACK_CHANNEL_ACC_DIV \
{ \
1, \
17, \
}
/* Fallback latency queue size. */
#define BACK_CHANNEL_FALLBACK_LATENCY_QUEUE_SIZE \
{ \
BACK_CHANNEL_FBK_0_LATENCY_QUEUE_SIZE, \
BACK_CHANNEL_FBK_1_LATENCY_QUEUE_SIZE, \
}
/* Fallback latency fifo size. */
#define BACK_CHANNEL_FALLBACK_LATENCY_FIFO_SIZE \
{ \
(BACK_CHANNEL_FBK_0_LATENCY_QUEUE_SIZE * ((BACK_CHANNEL_BIT_DEPTH + 7) / SAC_BYTE_SIZE_BITS)), \
(BACK_CHANNEL_FBK_1_LATENCY_QUEUE_SIZE * ((BACK_CHANNEL_BIT_DEPTH + 7) / SAC_BYTE_SIZE_BITS)), \
}
Audio Interface
The application receives audio from the line in of either the Coordinator or the Node, utilizes the audio codec to transmit it over the I2S line using DMA transfers, and outputs the audio to the headphone out of the opposite device.
The audio core pipeline processes audio samples coming from the I2S to format them to be sent over the air using the SWC. The I2S end of transfer callback and the SWC transmission success callback will trigger the audio processing to synchronize the I2S production rate and the SWC consumption rate.
Figure 27: Audio application timings.
Figure 28: Audio application processes.
When a packet transmission fails, the audio packets will accumulate in the audio consumer queue until the wireless core can transmit it’s payloads and free a space in its queue.
Figure 29: Audio application timings.
The application receives audio from the USB audio interface at either 1 kHz (USB Full-Speed) or 8 kHz (USB High-Speed) depending on the capabilities of the device.
Note
When using USB audio, the host computer controls the playback. If audio playback stops on the host computer, no audio samples are receives on the device. This means that the audio connection will not send any packets.
These frames are then accumulated and splitted into audio packets to be sent to the audio pipeline for processing before being sent OTA using the SWC. When using The USB interface, the audio samples are already formatted to packed 24-bit.
On the receiving side, the audio packets received OTA are processed and sent to the USB audio interface where a FIFO will accumulate the samples.
Note
When using USB audio, the host computer controls the recording. If the audio recording stops on the host computer, no audio samples are read from the device. This means that the USB audio transmission FIFO will not be depleted and will eventually overflow. Once the recording resumes, the FIFO will be consumed again and will stabilize to the correct level to match the expected latency.
The bidirectional link also allows for the transmission of various data such as the status of a button and the link margin. The link margin makes it possible for the Coordinator to track the quality of the connection, thereby switching between fallback and normal modes as needed. This data is transmitted when the wireless is free. The transmission and reception of data are assigned the lowest priority, prioritizing audio transfers while still being capable of transferring this data.
The wireless schedule allocates 7 timeslots for the transmissions from the Coordinator and 2 timeslots for its reception. The schedule is designed to reserve more bandwidth for transmitting a higher-quality audio stream from the Coordinator to the Node.
In the UWB frequency range, the wireless core alternates between 4 different frequency bands at each transmission.
Application Schedule
The following diagram illustrates the general structure of the schedule used in this application.
Figure 30: Audio Bidirectional Application’s Schedule.
Pairing
On boot, devices attempt to pair automatically. If unsuccessful, manual pairing can be performed afterward to use the application.
- Auto Pairing:
On boot, devices automatically start the pairing process. RGB blinks blue twice to indicate that pairing is in progress.
If the pairing procedure is unsuccessful, RGB blinks red twice after 10 seconds.
Once successfully paired, RGB turns green, and the devices begin exchanging application data.
- Manual Pairing:
Press the SW1 button on both devices to start the pairing procedure; RGB blinks blue twice when doing so.
If the pairing procedure is unsuccessful, RGB blinks red twice after 10 seconds.
Once successfully paired, RGB turns green, and the devices begin exchanging application data.
- Unpairing:
When paired, pressing the SW1 button again unpairs the device; RGB blinks red twice to indicate that unpairing has been completed.
Unpairing causes the devices to forget their learned addresses. The devices are no longer able to exchange application data.
To start a new pairing procedure, both devices must be unpaired first.
Fallback
The transmitter continuously monitors the link quality. If the link quality degrades, the application will dynamically reduce the audio packet size to increase output power settings. The system applies fallback independently on the main channel and the back channel. Each fallback level progressively reduces the required air throughput by modifying the sample rate, bit depth, or compression scheme. While in fallback mode, if the link quality remains strong for a specified amount of time and the CCA try count stays below a defined threshold, the system will revert to normal mode. The thresholds for entering and exiting fallback mode differ, creating hysteresis to prevent the system from toggling frequently in conditions of marginal link quality.
Main Channel Fallback
The main channel supports three audio fallback modes.
Fallback Mode 1 - 48kHz/24-bit Uncompressed
Processing stages:
Audio accumulator (1.7x)
Downsampling from 96 kHz to 48 kHz
This mode accumulates a higher number of samples per packet then halves the sampling rate while maintaining 24-bit resolution, lowering the application’s throughput and improving link robustness. If the link quality remains strong for 5 seconds and the CCA try count stays below a defined threshold, the system will revert to normal mode.
Fallback Mode 2 - 48kHz/16-bit Uncompressed
Processing stages:
Audio accumulator (1.7x)
Downsampling from 96 kHz to 48 kHz
Packing to 16-bit samples
This mode further reduces throughput by decreasing bit depth from 24-bit to 16-bit. Audio quality is reduced but link margin is significantly improved. If the link quality remains strong for 4 seconds and the CCA try count stays below a defined threshold, the system will revert to normal mode.
Fallback Mode 3 - 48kHz ADPCM
Processing stages:
Audio accumulator (2.3x)
Downsampling from 96 kHz to 48 kHz
ADPCM compression
This mode accumulates a higher number of samples, halves the sampling rates and employs the ADPCM algorithm for audio data compression. This compression algorithm reduces audio samples by a factor of 4. This stage helps lower the application’s throughput to increase range while still ensuring relatively good audio quality. If the link quality remains strong for 2 seconds and the CCA try count stays below a defined threshold, the system will revert to normal mode.
Back Channel Fallback
The back channel supports one audio fallback mode. It employs the ADPCM algorithm for audio data compression. If the link quality remains strong for 5 seconds and the CCA try count stays below a defined threshold, the system will revert to normal mode.
Clock Drift Compensation (CDC)
Clock Drift Compensation (CDC) is used to adjust the timing difference between the two devices. The Coordinator is the reference clock. Therefore, for the stereo audio Main Channel stream, the Node can use its internal PLL (when hardware allows) to adjust its clock frequency to the Coordinator’s. For the mono audio Back Channel stream, the Coordinator cannot modify its clock since it is the reference. CDC is therefore performed by using software resampling. For more information regarding CDC, refer to Clock Drift Compensation.
Board User Interface
The board user interfaces are identical for the Node and the Coordinator and includes LEDs, RGB and button switches.
Interface |
Name |
Description |
|---|---|---|
SW1 |
Pairing process |
Pair, unpair, or abort the pairing process depending on the current state. |
SW2 |
Fallback selector |
Cycle through all fallback modes and turn on the LED state of the remote device. |
SW3 |
Volume up |
Raises the received audio volume (default at 100%). |
SW4 |
Volume down |
Lowers the received audio volume. |
LED1 |
Transmission success |
Toggles every time an audio packet is successfully transmitted. |
LED2 |
Reception success |
Toggles every time an audio packet is successfully received. |
LED4 |
Fallback selection |
Turn on upon manually changing fallback mode. |
RGB |
Pairing Event |
Indicate pairing event as described in the pairing section. |
Note
LEDs assigned to transmission or reception status are almost always on because of the high packet rate.
Audio volume can be adjusted by the receiving device, meaning both the Coordinator and Node control the output gain of their respective streams. This control is managed through the SW3 and SW4 buttons.
Certification
This application has the ability to run in Certification Mode.
Different levels of certification are required to test the fallback modes and data connection.
Depending of which mode is requested, the
max_payload_sizeof the audio connection will be changed.The order in which connection are initialized and their priority will be swapped if the data connection needs to be tested.
Activating the Certification Mode
Table 32: Certification Mode Activation Certification Mode
Activation Process
96kHz/24-bit Audio
Hold SW2 at startup until the LED 1 blinks once, then release.
48kHz/24-bit Audio
Hold SW2 at startup until the LED 1 blinks twice, then release.
48kHz/16-bit Audio
Hold SW2 at startup until the LED 1 blinks three times, then release.
48kHz ADPCM Audio
Hold SW2 at startup until the LED 1 blinks four times, then release.
Control Data
Hold SW2 at startup until the LED 1 blinks five times, then release.
Terminal
The following figure shows the terminal output of this application.
See Viewing the Terminal for details on how to view the terminal output.
Figure 31: Puretone Headset Terminal Output - Audio Core (from left: Coordinator & Node).
Figure 32: Puretone Headset Terminal Output - Wireless Core (from left: Coordinator & Node).
See Audio Core API - Statistics and Wireless Core API - Statistics for more details.