Most example assumes audio is routed through hardware I2S/PCM pins. I assume you changed it to use WICED_BT_SCO_OVER_APP_CB.
I think wiced_bt_sco_output_stream() returns the number of bytes left on the (internal?) output buffer, and I assume wiced_bt_sco_output_stream() calls need to be throttled/timed so that the buffer is not overflown.
It was suggested to me that I call wiced_bt_sco_output_stream() in the sco receive data callback (wiced_bt_sco_data_cb_t), and transmit the same amount of bytes received. It worked in my test project based off of the AG example.
Thank you very much for your response. Your assumptions are correct. We changed the route and use the call back:
.path = WICED_BT_SCO_OVER_APP_CB,
.p_sco_data_cb = handsfreee_hf_data_cb
I tried to follow your suggestion with a simple change of my code. I disabled the call to wiced_bt_sco_output_stream() at the original location and inserted it into the callback shown above. Therefore I just echo the PCM data that has been received in the callback and send it back using wiced_bt_sco_output_stream().
Anyway the behavior is the same. After 7 calls to wiced_bt_sco_output_stream() with return 0, I get a return value of 120 (which is the size of passed PCM data) for every additional call.
In the end I do no hear any sound on the receiving side (smartphone hfp connected).
You mentioned "I think wiced_bt_sco_output_stream() returns the number of bytes left on the (internal?) output buffer", how sure are you about that? When do you think it is OK to send new data? Is there a test of threshold function or what is the size of the internal buffer. It is strange that the number is not increasing if no data is sent. Is there anything else to configure or enable to get the audio route going?
Thank and regards
I went back to my test project and every time I called wiced_bt_sco_output_stream(), 0 was returned. So I think you were right in that the output function returns # of bytes not accepted.
Maybe the difference here is I'm running the AG example and you HFP. As an audio gateway the receive data is sent by the headset (mic data), and the headset is pacing the data rate correctly. So if I transmit at the same rate as I receive data, I'm not overflowing any buffers.
Are you using the BTSpy tool to log debug traces? Try add a debug print everytime sco data callback is triggered and see how fast you are receiving data from the phone (I suspect the phone side is sending too fast).
08:29:21.856 2 SCO cb - tx: tx_n=120, tx_i=120, stream_remaining=0
08:29:21.863 2 SCO cb - tx: tx_n=120, tx_i=240, stream_remaining=0
08:29:21.871 2 SCO cb - tx: tx_n=120, tx_i=360, stream_remaining=0
08:29:21.878 2 SCO cb - tx: tx_n=120, tx_i=480, stream_remaining=0
08:29:21.886 2 SCO cb - tx: tx_n=120, tx_i=600, stream_remaining=0
08:29:21.893 2 SCO cb - tx: tx_n=120, tx_i=720, stream_remaining=0
08:29:21.901 2 SCO cb - tx: tx_n=120, tx_i=840, stream_remaining=0
I get 120 bytes every 7.5ms (16 bit per sample, at 8kHz sample rate).
1 of 1 people found this helpful
Andreas Kohn wrote:
Our problem is to send speech audio samples back in the other direction. In the examples I can not find the location where this is done, therefore we use this function to hand-over speech audio PCM samples to the Wiced lib: wiced_bt_sco_output_stream().
Yes, this is the correct function if you acquire the audio samples from a serial interface other than I2S. However, if your audio data will be sent over I2S, all of this work is done for you and there is no need to use this API. Once the SCO connection starts, the I2S bus will automatically start clocking data from a microphone or codec that is attached.
Can you confirm that your audio data is coming from a serial interface other than I2S in your end design? Essentially, can you confirm that you need to be using the wiced_bt_sco_output_stream API?