Audio Bidirectional
Description
The Audio Bidirectional application uses the SPARK Wireless Core to transmit a stereo audio stream with 48kHz/24-bit depth from the line-in connector of the Coordinator to the headphone connector of the Node (the Main Channel), and conversely, a mono audio stream with 32kHz/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 a compressed audio stream on both sides. The audio stream will revert to uncompressed once the link quality returns to normal.
Behavior
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 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 17: Audio Bidirectional Application’s Schedule.
Pairing
By default, devices are unpaired at boot. To use the application, start by pairing the devices.
- Pairing:
Press the SW1 button on both devices to start the pairing procedure; RGB should blink blue twice when doing so.
If the pairing procedure is unsuccessful after 10 seconds, the pairing process stops and the RGB should blink red twice.
Once the pairing procedure is successfully completed, the RGB turns magenta and the devices can start exchanging application data.
- Unpairing:
When paired, pressing the SW1 button again unpairs the device; the RGB should blink red twice to indicate the unpairing procedure is in progress.
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.
Note
LED behavior changes in pairing mode versus normal execution mode. During pairing mode, LEDs indicate pairing status as described below. Once paired, LEDs indicate packet transmission and reception and fallback mode status.
- Pairing:
Press the SW1 button on both devices to start the pairing procedure; LED0 should blink twice when doing so.
If the pairing procedure is unsuccessful after 10 seconds, the pairing process stops and all the LEDs blink twice.
Once the pairing procedure is successfully completed, the LEDs will cascade and the devices can start exchanging application data.
- Unpairing:
When paired, pressing the SW1 button again unpairs the device; All LEDs should blink twice to indicate the unpairing procedure is in progress.
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 Coordinator continuously monitors the link quality. If the link quality degrades, the system will enter fallback mode to compress audio packets on both sides. It 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. While in fallback mode, 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. The thresholds for entering and exiting fallback mode differ, creating hysteresis to prevent the system from toggling frequently in conditions of marginal link quality.
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 or unpair the device depending on the current state. |
SW2 |
Button activity |
Toggles 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. |
LED3 |
Fallback status |
LED is OFF in Normal mode and ON in Fallback mode. |
LED4 |
Button state |
Toggles upon receiving button state. |
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.
The board user interfaces are identical for the Node and the Coordinator and includes LEDs and button switches.
Interface |
Name |
Description |
|---|---|---|
SW1 |
Pairing process |
Pair or unpair the device depending on the current state. |
SW2 |
Button activity |
Toggles the LED state of the remote device. |
LED0 |
Audio transfers success |
Toggles every time an audio packet is successfully transmitted or received. |
LED1 |
Fallback status |
LED is off in Normal mode and on in Fallback mode. |
LED2 |
Button state |
Toggles upon receiving button state. |
Note
LEDs assigned to transmission or reception status are almost always on because of the high packet rate.
Audio volume cannot be adjusted using this hardware as only two buttons are available.
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_size of 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.
Table 24: Certification Mode Activation Certification Mode
Activation Process
Audio Uncompressed
Hold SW2 at startup until the LED 1 blinks once, then release.
Audio Compressed
Hold SW2 at startup until the LED 1 blinks twice, then release.
Control Data
Hold SW2 at startup until the LED 1 blinks three 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 18: Audio Bidirectional Terminal Output (from left: Coordinator & Node).
See Audio Core API - Statistics and Wireless Core API - Statistics for more details.