How do I get a working sample of the ble_android_asha code in RSL10 development board?

I want to connect my RSL10 development board running the ble_android_asha sample program to a smartphone and do audio streaming. I am following the sample code provided here: Issue in receiving audio data in RSL10 - 'BLE-IOT-GEVB ' - #14 by martin.bela
so that I can get audio output through DIO pins on the development board.

If I understand correctly, using ble_android_asha app, I can pair the development board with the smartphone and I will be able to stream music played on the smartphone to the development similar to a classical A2DP audio streaming.

I download the sample code in the development board, connected receivers to DIO0 and DIO1 as it said in the previous link. I cannot hear any audio. For the log messages seen in RTT viewer it looks like the BLE data is getting detected, but I can’t hear any decoded audio. Here is a sample of some of the log messages that I can see:

==============================================

===== Initializing ble_android_asha_OD LEFT =====

==============================================

sending GAPM_LEPSM_REG_CMD…
GAPM_LEPSM_REG: LEPSM registered successfully
GAPC_CONNECTION_REQ_IND: con_interval=39, con_latency = 0, sup_to = 500, clk_accuracy = 1
ADDR: 72 87 246 37 235 127
ADDR_TYPE: 1
Starting GAPM_ResolvAddrCmd

GAPM_ADDR_SOLVED_IND connectionCfm->ltk_present = 1

GAPC_BOND_REQ_IND / GAPC_PAIRING_REQ: accept = 1 conidx=0
GAPC_BOND_REQ_IND / GAPC_CSRK_EXCH
GAPC_PARAM_UPDATE_REQ_IND: intv_min=6, intv_max = 6, latency = 0, time_out = 500
GAPC_PARAM_UPDATE_REQ_IND: intv_min=39, intv_max = 39, latency = 0, time_out = 500
ASHA_ReadOnlyProperties_Callback: conidx=0 length=17
ASHA_LE_PSM_Callback: conidx=0, length=2, le_psm=0x 0A8
ASHA_MsgHandler: L2CC_LECB_CONNECT_REQ_IND le_psm=0xA8
ASHA_MsgHandler: L2CC_LECB_CONNECT_IND: peer_cid=79
GAPC_PARAM_UPDATE_REQ_IND: intv_min=16, intv_max = 16, latency = 10, time_out = 100
ASHA_Volume_Callback: conidx=0 volume=0
APP_ASHA_CallbackHandler - ASHA_VOLUME_CHANGE: volume=0

ASHA_AudioControlPoint_Callback: opCode=3 codec=2 audioType=16 volume=0, otherState=0

APP_ASHA_CallbackHandler - ASHA_AUDIO_STATUS. Other peripheral state: 2

ASHA_Volume_Callback: conidx=0 volume=0
APP_ASHA_CallbackHandler - ASHA_VOLUME_CHANGE: volume=0

ASHA_AudioControlPoint_Callback: opCode=1 codec=1 audioType=0 volume=-128, otherState=0

APP_ASHA_CallbackHandler - ASHA_AUDIO_START: codec=1 audiotype=0 volume=-128

APP_Audio_Transfer: seqNum_prev = 255, seqNum = 10
Established

ASHA_AudioControlPoint_Callback: opCode=2 codec=1 audioType=0 volume=-128, otherState=0

APP_ASHA_CallbackHandler - ASHA_AUDIO_STOP

Disconnect

ASHA_AudioControlPoint_Callback: opCode=1 codec=1 audioType=0 volume=-128, otherState=0

APP_ASHA_CallbackHandler - ASHA_AUDIO_START: codec=1 audiotype=0 volume=-128

APP_Audio_Transfer: seqNum_prev = 255, seqNum = 7
Established

ASHA_AudioControlPoint_Callback: opCode=2 codec=1 audioType=0 volume=-128, otherState=0

APP_ASHA_CallbackHandler - ASHA_AUDIO_STOP

Disconnect

This is when pressing the volume keys and pressing the start and stop buttons on the music player in the smartphone.

What do I have to do to get audio output? Currently I don’t have the LPDSP32 tools installed. Do I need to install LPDSP32 tools first? Do I need to download ble_android_asha app first and the LPDSP32 app separately? If this is true where is the source code for the required LPDSP32 app?

What do I need to prepare in order to do a successful BLE audio streaming using the ble_android_asha sample app?

My current hardware: RSL10−002GEVB (RSL10 QFN EVB v1.3 from May 2017)
Software: ON Semiconductor IDE Version: 3.4.0.48, CMSIS pack 3.5.285
Phone: Samsung Galaxy s10e Android 11

Hi @mahaju,

Please see my feedback below:


No, the LPDSP32 tools are not necessary to evaluate the ASHA sample code. We have implemented G.722 and CELT/OPUS codec on the LPDSP32 for our users to take advantage of, so there is no need to customize these if they meet your needs. If you wish to make changes to or expand the codec implementations, you will need the LPDSP32 tools.


No, this sample application already has the DSP firmware internal and will copy the firmware into the DSP PRAM using the RSL10’s ARM Cortex M3 processor.


By default, you will require an E7100 Evaluation board to perform the audio rendering. If you are using the OD code provided in the Topic mentioned above, you will simply need an audio receiver capable of playing back the balanced OD audio output.

This can usually be done by attaching the DIO pair to the balanced input pins of an XLR receiver, or by attaching each of the pins to the left and right bands on a TRS headphone jack (the ground ring should be left floating).


you mean the required code for LPDSP32 is already in the sample application? Does this get downloaded when I download the ble_android_asha sample code from eclipse? Why isn’t it generating any sound then, when the RTT log messages seem to show BLE is working? The receiver I am using now can be used to generate a passthrough sound from the DMIC_OD sample program, so the receiver itself is compatible with the development board. I cannot use a 7100 board so I would prefer to render the audio from the RSL10 board itself. Do you have any suggestions on how to troubleshoot this? Is there any way to send the rendered audio data to PC and save in a file?

Hi @mahaju,

This is correct. The LPDSP32 software is already included within the ASHA project files and is placed in the proper DSP PRAM locations during firmware startup.


Given the DMAIC_OD sample code is working for you, that means your playback devices are working as expected. A few things you can check are:

  1. Is the OD positive and negative DIO pins set the same as the DMIC_OD sample? This pair can be set to any two DIO pins, so it is important to verify that your playback device is interfaced with the OD properly.
  2. Is the volume set appropriately within your ASHA capable device? The RTT messages you have shared above seem to suggest that the Volume Key exchange message is always set to a value of zero.
  3. Did you connect to the RSL10 through the Android Hearing Aid Accessibility menu? This can be done by opening “Settings > Accessibility > Hearing enhancements > Hearing aid support > Bluetooth hearing aid”.

To achieve this you will need some way of sampling the OD output audio and transferring it onto the PC. For our internal testing, we take the OD output pins and connect them to an XLR connector on a PC audio interface. The audio interface will then be attached via USB to the PC, which allows the samples audio to be recorded directly on the PC.


Actually the volume value changes every time I press the volume +/- buttons. I had a lot of other volume messages as well but I didn’t post them here for brevity. The “volume” value on this line

codec=1 audiotype=0 volume=-128

changes every time I press the volume buttons, it’s not always -128, so the volume level is probably not the issue. The “audiotype” parameter is an enum with 4 values, and it seems to be 0 every time, which is defined in the program as “AUDIO_UNKNOWN”. “audiotype” is 16 when this log message appears for the first time

ASHA_AudioControlPoint_Callback: opCode=3 codec=2 audioType=16 volume=0, otherState=0

while the enum defining audiotype only has 4 entries so it’s value should not be more than 3. Are these two facts indicating a problem?

Yes this is how I connected. Do you have any custom android apps for testing this sample program, or they aren’t necessary?

They probably are, but I’ll have to check again when I can. However in the DMIC_OD sample program I think I had changed the default output DIO pins to something else, that is, the DIO pins that I used for output are different from the DIO output pins specified in the sample code. If I remember correctly I had probably used DIO 0 and 1 as well, but I’ll have to have a look at the program again.

Since I cannot hear any output sound right now I don’t think recording this way will save any sound either. I was more wondering whether the generated audio data that gets sent to the OD, can be sent to the PC through the RTT connection instead and saved from there. This way I would know that at least BLE decoding is happening and audio samples are getting generated even if the receiver isn’t playing anything.