How to receive SGTL5000 I2S data?

[Dipak]

Hello Team,

My goal:

Live audio streaming over BLE

What I have done:

I have interfaced SGTL5000 with NRF52832 and I follow this link.

github.com/.../nRF52-teensy-sgtl5000-audio

and loopback [Microphone to earphone] is perfectly working!

problem:

I want to receive I2S data from SGTL5000 so I can store live audio data inside NRF52832.

So for this, I have made the following  changes

1) I have added the below function inside the i2s_data_handler function when the loopback event called. [ condition SGTL5000_STATE_RUNNING_LOOPBACK when becomes true ].

2) I have added the below function inside the i2s_data_handler_old function

above 2step modification i have done in drv_sgtl5000.c file.

3)I have also modified in DRV_SGTL5000_EVT_I2S_RX_BUF_RECEIVED event in main.c

4)In main.c I printing all the data as shown below. 

As per my understanding, I have made the above changes to receive I2S data from SGTL5000.

Result:

I m getting zeros with some data in RTT viewer [printing data using NRF_LOG_INFO]

I have converted this data into a .wav file and when I played the file then I notice that only noise is recoreded.

So, I don't know these changes are right or wrong.

Please note:

- I have used SDK_15.0.0 

-NRF52832 controller

looking forward to your reply!

-Dipak

[Einar Thorsrud]

Hi Dipak,

The Nordic UART services is a good choice for sending large chunks of data. It essentially demonstrates sending notifications, which is what you want. The NUS example use long packets but perhaps you want to increase the event length by adjusting NRF_SDH_BLE_GAP_EVENT_LENGTH in order to support a higher throughput.

From that point, you just call ble_nus_data_send() continuously with your data. This will call sd_ble_gatts_hvx() which copies the data into a queue within the SoftDevice, so there is no risk of the data being overwritten.

You need to handle the situation where the queue is full, and in that case wait for the BLE_GATTS_EVT_HVN_TX_COMPLETE event before trying to send again. As you want to achieve "live" streaming it probably makes most sense to drop data if the queue is full instead of trying to send it later.