KB: Audio Stream Broadcast Custom Protocol (Remote Mic Protocol) Sample Applications for RSL10

[RSL10 - Knowledge Base]


RSL10 is a fully capable Wireless Audio Streaming solution that comes with several sample applications demonstrating these capabilities.

There are 3 variants of the “remote_mic...” sample application available within the RSL10 Software CMSIS-Pack. Each of these variants has a Transmit (Tx) and Receive (Rx) version that demonstrate the following functionalities within the RSL10:

  • Digital Audio I/O
  • Codec Encoding and Decoding (G.722 and CELT/OPUS)
  • Audio Stream Broadcast Custom Protocol (Remote Mic Protocol)
  • Asynchronous Sample Rate Conversion (ASRC)

What are the I/O and functional variations between each of the projects?


remote_mic_tx_raw & remote_mic_rx_raw

Digital Audio Input Dual Channel @ 16kHz Dual Channel @ 32kHz Dual Channel @ 32kHz -
Digital Audio Output Single Channel @ 16kHz - - Single Channel @ 16kHz

remote_mic_tx_coex & remote_mic_rx_coex

Same functionality as the “raw” version of the sample above, with the added capabilities of maintaining concurrent Bluetooth Low Energy connections alongside the Audio Stream Broadcast Custom Protocol. This sample fulfills the Peripheral role and also demonstrates a Custom Service that can be used during audio streaming.


Interface SPI
Encoded Digital Audio Input G.722 or CELT(OPUS), Dual Channel @ 16kHz
Encoded Digital Audio Output G.722 or CELT(OPUS), Single Channel @ 16kHz

More information about using any of the RSL10 Sample applications is available within the RSL10_sample_code_users_guide, found in our RSL10 Documentation Package.

Using SPI how a spi-frame is composed to be sent to RSL10 using remote_mic_tx_coex or the remote_mic_tx_raw ?
single sample left or right using 16bit @ 16KHz?
dual sample left-right (or backwards) using 16bit @ 16Khz.

Hi @oscar,

When using SPI to pass in audio samples to these sample application, the packets are sent it bursts of 4x left and 4x right packets which are 16bit and equate to a sampling rate of 16kHz.

That is, you will see the following data layout when observing the 16x16bit DMA transfer buffer that is receiving SPI samples:

[16b Left][16b Left][16b Left][16b Left][16b Right][16b Right][16b Right][16b Right][16b Left][16b Left][16b Left][16b Left][16b Right][16b Right][16b Right][16b Right]

thanks for your help.

by the way, what will be the format for the receiver using SPI too?

Hi @oscar,

The SPI clock-rates and word sizes are outlined in the table below. Each sample application will use an active-low Chip Select and Normal Polarity.

Sample Firmware SPI Word Size SPI Clock
remote_mic_trx_coded (Input) 8 bit 1MHz (48MHz / 3 / 16)
remote_mic_trx_coded (Output) 8 bit 500kHz (48MHz / 3 / 32)
remote_mic_tx_raw/coex 16 bit 3MHz (48MHz / 1 / 16)
remote_mic_rx_raw/coex 16 bit 500kHz (48MHz / 3 / 32)

I’m wondering is SPI frame format for the remote_mic_rx_coex (SPI_TX_RAW_OUTPUT) is as follows?
[16b Left][16b Right]


Hi @oscar,

No, when receiving audio samples over the SPI interface in this sample application, it will expect the samples in bursts of 4x 16bit per channel.

That is, you should be sending:

[16bit left] [16bit left] [16bit left] [16bit left]
[16bit right] [16bit right] [16bit right] [16bit right]

,in an alternating fashion so that the samples equate to ~16kHz audio.

ok, SPI format same as for RX and TX.


Hi @oscar,

I misunderstood the question and answered in regards to the TX version of the sample application.

When using the ‘remote_mic_rx_coex’, the output SPI stream will be 16bit audio sample @ 16kHz for a single audio channel. If you would like to playback stereo audio, you will need 3 RSL10 devices. One TX device and two RX devices to playback each audio channel.

So, TX will look to pair two RX RSL10? or could I just use a single RX RSL10 and use it as a mono for a quick test?


Hi @oscar,

There is no pairing necessary.

The Remote Mic Protocol is a broadcast protocol, so playback will only depend on how many RX devices are listening for specific channel packets on the same ‘access word’ (essentially a BLE Address for our custom protocol).

It is not necessary to have two RX devices, as having a single RX devices listening on the transmission access word will pickup all of the Left or Right channel packets.


Thanks for the clarification. I will test it in mono for now.