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.

CC2564MODA: bluetooth listing test fails

Part Number: CC2564MODA

Hi,

Customer uses CC2564MODA with bluetopia stack 1.2R for Tiva.
http://www.ti.com/tool/CC256XM4BTBLESW

They are at final Bluetooth listing phase, but test fails with below two formats.
A2DP/SNK/CC/BV-01-1

A2DP/SNK/CC/BV-02-1


Their software is based on A2DP demo in our SDK.
I guess our software should pass these tests without problems.
What is the potential causes of the failures?
This is production stop issue for customer.

Thanks and regards,
Koichiro Tashiro

  • Koichiro,

    This appears to be related to the A2DP issue we worked on month ago. Can you provide more detail on how we fail these tests?

    Also, what is the testing criteria here? It says "SNK can play through speaker with acceptable quality". Is this what we failed on? was audio quality bad?

    BR,

    Vince 

  • Hi Vince,

    Sorry for the delay. I am asking the details of the failing criteria, etc and waiting for answer from customer.

    Meanwhile, could you confirm the original A2DP demo in our SDK supports these formats without any issues?

    Thanks and regards,
    Koichiro Tashiro

  • HI Koichiro,

    I don't see any settings that we wouldn't be able to use on the TIVA. Remember though with the emulated I2S, you need to create X and Y values that allow you to switch between frequencies across all bit rates (Mono/Stereo, 44.1/48khz)

    BR,

    Vince 

  • Hi Vince,

    Sorry for the delay.
    Customer does not get detailed failing reasons from their test house, yet.
    So they wants to try these two formats by themselves.
    Do you know there are any tools(PC, smartphone, etc.) available to generate such SBC formats?

    Thanks and regards,
    Koichiro Tashiro

  • Hi Vince,

    I have additional information from customer.
    The test house said;
    - There is no problem to play normal audio formats
    - These failing formats(attached in my first post) are something different from normal audio formats and no music is played.

    I checked Bluetopia Subband Codec API document (SubbandCodecAPI.pdf) in SDK and confirmed all parameters are supported by SBC_Decode_Data API.
    But I am not sure all parameters are supported in A2DPDemo example code.
    What I can find in A2DPDemo.c is below configuration. It seems the code specify sampling rate, channel mode and decoding format(SBC).

    static AUD_Stream_Format_t AudioSNKSupportedFormats[] =
    {
    	{ 44100, 2, 0 },
    	{ 48000, 2, 0 },
    	{ 48000, 1, 0 },
    	{ 44100, 1, 0 }
    };


    Where can I find the codes specify subbands, allocation method and block size?
    Does A2DPDemo supports these two formats?

    Thanks and regards,
    Koichiro Tashiro

  • Hi Vince,

    The issue was root caused.

    The A2DPDemo code specifies the number of audio samples as 128 regardless SBC format.
    In AudioDecoder.c:

    	/* The following defines the number of audio samples that are		*/
    	/* generated for each SBC frame.										*/
    #define NUM_AUDIO_SAMPLES_PER_SBC_FRAME							 128
    


    But for some SBC formats, the number of audio samples are 64. So the code exits from while loop here.
    In AudioDecoder.c, Decode() function:

    			/* Make sure that there is enough room to contain the samples	*/
    			/* from a single SBC frame.										*/
    			if(DecodedData.ChannelDataSize < NUM_AUDIO_SAMPLES_PER_SBC_FRAME) {
    				break;
    			}
    


    For correct operation, NUM_AUDIO_SAMLES_PER_SBC_FRAME must be adjusted depending on decoded SBC format, either 64 or 128.

    I knew the Bluetopia is qualified as QDID42849 and all SBC formats are supported.
    Customer complains why A2DPDemo itself does not support all SBC formats.
    Was there any reasons Bluetopia could not provide the exact codes with which they got QDID?

    Thanks and regards,
    Koichiro Tashiro

  • My take on this one is that the QDID is extremely old and didn't come from TI directly.  The A2DPdemo is that, only a demo, we do not know what software was used by Stonestreet One to attain the QDID. Was the customer able to pass after the adjustments to the frame size?

    Regards,

    Travis

  • Hi Travis,

    Customer wants to get the exact code used by Stonestreet.
    Could you ask them to provide the code?

    >Was the customer able to pass after the adjustments to the frame size?

    Not, yet. They will try later.

    Thanks and regards,
    Koichiro Tashiro

  • Can you confirm if this is A2DP or A3DP?

    Also, the profile may not support all the SBC formats that their ICS product test plan is testing.  Did they compare the ICS again the one from our QDID?  This is important to check first.

    I talked to Cloud2gnd, our 3rd party who supports Bluetopia stack and profiles customizations etc, they believe the demo code is what was used to achieve the certification and are looking to see if any other demo versions are available.

    Regards,

    Travis

  • Hi Travis,

    This is for A2DP.

    I double checked QDID42849 ICS details in SIG website (Launch Studio).
    Here are snap shots from the page.
    As you can see the last table, all codec features (channel mode, block length, subbands and allocation) are supported.




    Thanks and regards,
    Koichiro Tashiro

  • Tashiro-san,

    I discussed with Cld2gnd and it isn't apparent which exact demo code was used by Stonestreet One for certification.  They reviewed the thread and there probably isn't enough information to conclude on root cause of the issue, but the suggestion would be to review the failing case and perhaps either dedicate a larger buffer size, or a variably sized NUM_AUDIO_SAMPLES_PER_SBC_FRAME might fix this. If the customer is not able to solve the issue, they could contact Cld2gnd and contract with them to solve the issue.

    Has the customer had any additional testing done?

    Thanks,

    Travis

  • Hi Travis,

    Thanks for working with Cld2gnd.
    I am not sure why they cannot conclude on root cause of the issue based on the information provided this thread.

    The code is break at here, because DecodedData.ChannelDataSize remains 64 and NUM_AUDIO_SAMPLES_PER_SBC_FRAME is 128.
    (all codes below are in AudioDecoder.c)

    			/* Make sure that there is enough room to contain the samples	*/
    			/* from a single SBC frame.										*/
    			if(DecodedData.ChannelDataSize < NUM_AUDIO_SAMPLES_PER_SBC_FRAME) {
    				break;
    			}


    DecodedData.ChannelDataSize is calculated as below

                           // Calculate the amount of space available for audio samples.
                           if(PlaybackContext.OutIndex > PlaybackContext.InIndex) {
                                   DecodedData.ChannelDataSize = (unsigned int)(PlaybackContext.OutIndex - PlaybackContext.InIndex);
                           } else {
                                   DecodedData.ChannelDataSize = (unsigned int)(AUDIO_BUFFER_SIZE - PlaybackContext.InIndex);
                           }
    



    And PlaybackContext.InIndex is updated here

                                   // Adjust the Index for the Audio Samples that were just added.
                                   PlaybackContext.InIndex += DecodedData.LeftChannelDataLength;
    

    The DecodedData.LeftChannelDataLength is 128 for most SBC formats, this is why NUM_AUDIO_SAMPLES_PER_SBC_FRAME is 128 as default, I think.
    But for these failing SBC parameters, DecodedData.LeftChannelDataLength is 64, not 128.
    This makes DecodedData.ChannelDataSize=64 at the end, because AUDIO_BUFFER_SIZE is 128 * 8.
    More properly, after 15 SBC frames are decoded, remaining DecodedData.ChannelDataSize is 64.
    (128 * 8) – (64 * 15) = 64

    	/* Each SBC frame will yield 128 left samples and 128 right samples. */
    	/* Setup the buffer to hold 8 decoded SBC frames.					*/
    #define AUDIO_BUFFER_SIZE									 (128 * 8)
    



    Thanks and regards,
    Koichiro Tashiro

     

  • Hi Koichiro,

    I think this check is only really valid if your audio buffer is bound by a multiple of  NUM_AUDIO_SAMPLES_PER_SBC_FRAME, and if you were doing more dynamic memory allocation of buffers. Since the buffer is hard coded to 128 *  8 and created at compile time, this check loses some meaning. 

    Since the buffer is accounting for the max size of 128 already, I think the easiest change to do is remove the check. 

    It's my understanding you have done this and the example is now working, so that should make this issue resolved. 

    BR,

    Vince