Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

  • State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 52 subscribers
  • Views 1015 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

BLE Getting Started and FAQ [u: 2022 Mar 21]

CC2640R2F: Audio BLE Application

rongal
Prodigy 100 points
Part Number: CC2640R2F

I am a newcomer to BLE development, and have some questions relating to the application I need to create. I am comparing a couple of TI alternatives and would appreciate replies on how to go about putting together a POC (i.e. Project zero type) for learning and demonstration purposes.

My base requirements are as follows:

  1. BLE should interact with available smart phones supporting Bluetooth.
  2. The application requires:

2.1.        Primarily, bidirectional transfer of audio between the smart phone and external audio devices (loudspeaker, microphone, audio amplifier, etc.).
Transfer may be full (preferred) or half duplex.

2.2.        Secondly, low volume data messages (i.e. bit streams from and to the smart phone from an external hand-device or controller).

3. The audio signals need to be analog, not encoded in any way. The audio devices will be connected directly to the output of the module proposed.

4. Audio hi-fidelity is not a prerequisite.

5. The smart phone will, initially, run Android.

I could not find any reference in the TI Blog associated with Project Zero that dealt with audio implementations of BLE.

Two TI platforms have been suggested to me as possible solutions: the CC2640R2 and the CC1352.

My questions are as follows:

  1. What are the tradeoffs and comparisons between these two alternatives.
    1. Do they both support BLE 5 and backward versions of BLE?
    2. Do they come with the necessary Bluetooth stacks and profiles I need?
    3. Will they support my audio requirements?
    4. Will the Launchpads of either or both of these two alternatives support my application, and which support the implementation in an easier and more available manner?
    5. Is the A2DP profile the correct one to aim for?
      If so, do both platforms support it?
      If not, what is the recommended mode of operation for the audio signaling?
    6. Does the SDK and support provide any form of (audio) test application for the Android based smart phone?
    7. Are there any other alternatives I should be considering?
    8. Any additional insights would be welcome.
      In particular, guidelines and references relating to how to start and put together a suitable Project Zero/Demo, applying audio, in short order and minimal pain.

I am a newcomer to BLE development, and have some questions relating to the application I need to create.  I am comparing a couple of TI alternatives and would appreciate replies on how to go about putting together a POC (i.e. Project zero type) for learning and demonstration purposes.
My base requirements are as follows:

1.    BLE should interact with available smart phones supporting Bluetooth.

2.   The application requires:

2.1.        Primarily, bidirectional transfer of audio between the smart phone and external audio devices (loudspeaker, microphone, audio amplifier, etc.).
Transfer may be full (preferred) or half duplex.

2.2.        Secondly, low volume data messages (i.e. bit streams from and to the smart phone from an external hand-device or controller).

3.   The audio signals need to be analog, not encoded in any way.  The audio devices will be connected directly to the output of the module proposed.

4.   Audio hi-fidelity is not a prerequisite.

5.   The smart phone will, initially, run Android.

I could not find any reference in the TI Blog associated with Project Zero that dealt with audio implementations of BLE.
Two TI platforms have been suggested to me as possible solutions: the CC2640R2 and the CC1352.
My questions are as follows:

A.  What are the tradeoffs and comparisons between these two alternatives.

a.   Do they support BLE 5?

b.   Do they come with the necessary Bluetooth stacks and profiles I need?

c.   Will they support my audio requirements?

B.  Will the Launchpads of either or both of these two alternatives support my application, and which support the implementation in an easier and more available manner?

C.  Is the A2DP profile the correct one to aim for?
If so, do both platforms support it?
If not, what is the recommended mode of operation for the audio signaling?

D.  Does the SDK and support provide any form of (audio) test application for the Android based smart phone?

E.  Are there any other alternatives I should be considering?

F.   Any additional insights would be welcome.
In particular, guidelines and references relating to how to start and put together a suitable Project Zero/Demo, applying audio, in short order and minimal pain.

  • 0
    TI__Guru 57865 points

    Hi,

    rongal said:
    Do they both support BLE 5 and backward versions of BLE?

    Yes, Although CC2640R2 might not leave enough memory with the BLE5 build

    rongal said:
    Do they come with the necessary Bluetooth stacks and profiles I need?

    We Have some audio examples on a github repository, that builds on top of our official SDKs;

    rongal said:
    Is the A2DP profile the correct one to aim for?

    A2DP is a not a BLE Profile (It's only supported for classic bluetooth

    I hope this helps to evaluate further, especially the link to our audio examples.

  • 0 in reply to J Lindh
    Prodigy 100 points

    Thanks for the prompt response.

    1.  You mention that the CC2640R2 may not have sufficient memory to support the BLE5 build.
    How can I determine this in advance?

    Would you recommend applying a previous version of BLE (e.g. 4.2 or other) to ascertain sufficient memory resources on that platform?

    2.  I understand that A2DP relates to classic BT.  What is the equivalent relating to BLE?

    3. In the Github examples you refer to:  the example page that relates to SDK 2.40 does not open.  All other examples relate to previous versions of the SDK (2.20 and below). 

    The current SDK is apparently 2.40.  Can I use the examples prepared for the previous versions with this current version?

    4.  I think that the audio examples apply to audio streaming between two Launchpads.

    Is there any support or example that will link an Android smart phone to a CC2640R2 Launchpad? 

  • 0 in reply to rongal
    TI__Mastermind 33460 points
    Hi,

    1. I recommend using the out of the box simple_central and simple_peripheral examples and observe how much memory is available.
    From there you can compare that with the expected footprint size of your application.

    Just for example. Here is a ballpark estimate. Note that I am assuming I2S based on your requirements here:
    external audio devices (loudspeaker, microphone, audio amplifier, etc.)

    Let's say 16-bit mono audio, 120 samples per frame, buffer depth = 4. That results in ~1k minimum of RAM needed just for the I2S buffers. On top of that you will have to build your code.

    2. There is no standardized profile or audio distribution method for BLE. This is primarily done by custom profile implementations or Voice over HID over GATT. In either case, you will likely need to write an Android app that supports and discovers this profile.

    3. The Audio examples on Github are being deprecated in favor of a new Audio SDK that will be released later this year. You can still find them on SDK 2.30. They are not compatible with SDK 2.40 without some porting.

    4. This is correct. Again you will need to write some Android code to support the custom profile interface if you wish to stream to a phone.
    Also keep in mind that that this means the phone will need to support a low connection interval. We don't have an example for streaming to an app.