This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SBC Encoder/Decoder performance

Other Parts Discussed in Thread: TM4C1290NCPDT

I'm running on a Tiva C TM4C1290NCPDT at 120 mhz, using the Bluetopia FP library.

I have measured the number of CPU cycles / time it takes for the SBC codec to process a frame.

At a minimum, with interrupts turned off, I have it taking around 118k cycles / 0.987 milliseconds at a minimum to encode a frame to send out, and 142k cycles / 1.184 milliseconds to decode an incoming frame.

During this test, there were about 371 frames decoded and about 328 frames encoded every second. This means that per second, I am spending 44% CPU time decoding and 32% CPU time encoding. This is after what had to be dropped due to lack of available processor time (if I am not doing both at once, I can get more data in/out--the processor meanwhile has to do other things like user interface, dual-SPI driving to generate the I2S, etc.). I am not sure how to measure exactly how much time it's taking to transmit the data via UART, but I'm running the UART at 3 mbit if that gives you any idea how much time the processor is spending just transmitting the data to/from the module.

It seems that I must encode or decode frame by frame, and cannot give it a large chunk of data to save on any overhead from setting up the call (I get 8 frames at a time). I don't know how much this impacts the amount of time it spends, but given that it's so many frames per second, I'm sure that every bit counts.

Is this the expected performance of the SBC encoder/decoder included with the TI/Bluetopia Bluetooth stack?

Is there anything I can do to decrease the time it takes to decode & encode? Decreasing the bitpool did not seem to have any effect.

  • Hi,

    Let me check this internally and get back to you on this.

  • Hi,

    Please see the inputs i have received internally:

    1. I’m not sure why it is needs to do both encoding and decoding at the same time.. either you works as sink or as source depending on that you do decoding or encoding.
    2. your calculation seems right, but we don’t have the exact numbers presently.
    3. I don’t think that providing a chunk of frames instead of a single frame would be much more efficient (the encoder/decoder process is linear), if at all
    4. you can use A3DP. 
  • Thanks for the reply!

    1. It is encoding and/or decoding because there are multiple audio sources, one of which may be a Bluetooth source, and the output may be to a Bluetooth sink (or two sinks). Therefore, if the audio source is Bluetooth and the audio output is also Bluetooth, decoding + encoding at the same time.

    4. A3DP doesn't operate in both roles at once, so this seems a bit tricky. Plus, it doesn't support AAC decoding which is one of the things I have to do (I have a separate decoder for that). Is it a simple operation to switch assisted mode on/off depending on the codec being sent by the source, or would it involve reconnecting to the device in order to enable or disable?

    If I can use assisted source mode (i.e. offloading encoding to the CC256x) while still using non-assisted sink mode (having the host decode the incoming stream when it is present), that might work, too, but either way, one or the other will still have to be getting processed by the host since the CC256x doesn't currently allow assisted mode in both roles simultaneously. 44% CPU seems excessive for a codec that was supposed to be low complexity for use in simple processors. Is there any chance of optimizing the built-in SBC encoder / decoder in a future release?

    Much appreciated

  • Hi,

    Please see the inputs I have received internally.

    We’re not going to optimize the SBC encoder/decoder. 

    You can use one stream as A3DP (assuming SBC is ok), and the other stream as A2DP.. just like you suggested.

  • Thanks for the reply. I will try to set up A3DP output based on the multiroom demo.