4 Replies Latest reply on Dec 12, 2017 3:08 AM by JacobT_81

    sending speech audio data via HFP

    AnKo_2681891

      Hi,

      we are using Wiced 5.0.1 and have an implementation for HFP which is basically founded on the HFP example code from Wiced Studio. We are able to setup an HFP connection and receiving speech audio PCM samples. 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().
      This function indicates by return value, how many bytes have not been send by the stream. We encounter that roughly 7 packet of 120byte PCM sample will be sent by the function (return = 0), from there on no more data is sent by the stream. Maybe an internal buffer has been filled and then no more data is accepted.b

       

      Maybe we are on the totally wrong way of doing this, but can anyone point me to an example, that shows how to send speech audio data via HFP? This should be a basic feature of HFP and I am wondering why this is causing trouble using the wiced libraries.

       

      Thanks and regards

      Andreas

        • 1. Re: sending speech audio data via HFP
          LJYe_2922526

          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.

           

           

          • 2. Re: sending speech audio data via HFP
            AnKo_2681891

            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

            Andreas

            • 3. Re: sending speech audio data via HFP
              LJYe_2922526

              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).

              • 4. Re: sending speech audio data via HFP
                JacobT_81

                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?

                 

                Jacob

                1 of 1 people found this helpful