• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 54 subscribers
  • Views 470 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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:

LAUNCHXL-CC1310: Using OPUS codec based in CC1310

LAUNCHXL-CC1310: Audio codecs on CC13x2 / Audio SDK for CC13x2

Alexander Haß
Prodigy 170 points
Part Number: LAUNCHXL-CC1310
Other Parts Discussed in Thread: CC3200AUDBOOST, TLV320AIC3254, CC1310, SYSCONFIG

Hi!

I'm trying to implement audio data transmission between the CC1352P1 LaunchPads with the help of the CC3200AUDBOOST and the EasyLink driver from the SimpleLink CC13x2 CC26x2 SDK version 5.40.00.40. Now that I implemented a basic simplex audio data transmission between the boards, I have pretty much the same problems as the user in this other thread: my channel capacity is too low to use more than one audio channel at the same time. My understanding is, that the TLV320AIC3254 hardware codec does not compress the audio data. So here are my three questions regarding audio usage on the CC1352 Launchpads:

1. In the other thread, Clément said there will be an Audio SDK for the CC13x2/CC26x2 LaunchPads "latter this year, probably end of October". This was three years ago, so was this Audio SDK released in the meantime? If yes, where can I find it?

2. Is my understanding correct, that the TLV320AIC3254 codec on the CC3200AUDBOOST does not support any audio compression?

3. I also started to implement the Opus codec into my project in the hope it would help me, but at first glance this seems very complex. Compiling the Opus codec in CCS for the CC1352P1 seems to be a challenging task. Are there maybe some other ressources (SDKs, LaunchPads, boost packs, documentation etc.) that would help me implementing a reliable wireless audio transmission in a fast way that I'm missing?

I'm currently a little bit lost on this topic, so any help would be appreciated.

Best regards,

Alex

  • 0
    TI__Guru* 85741 points

    Someone is assigned to this case and come back to you.

    BR

    Siri

  • +1
    TI__Guru** 101450 points

    Hi Alex,

    To be clear, I don't think Opus can be run on CC1310 - I am telling you this as the thread mentions this device, even it looks like you are rather looking at CC1352/CC1312.

    1- The Audio SDK can be found here: https://dev.ti.com/tirex/explore/node?node=AFFVIsO6lK9zZEzi2G-Sig__RW99gST__LATEST

    2- Correct, the TLV320AIC3254 does not perform audio compression. Audio compression can be performed by a software codec (e.g. Opus)

    3- I would recommend to leverage the examples available in the SimpleLink Audio Plugin.

    I hope this will help,

    Best regards,

  • 0 in reply to Clément
    Prodigy 170 points

    Hi Clément,

    thank you for your reply. Yes, you understood correctly, I do not have the intention to implement a software codec on the CC1310. I just clicked on "Ask a related question" on the other thread.

    After installing the rfAudioRx/Tx examples, which was another issue in itself (here the link to my other thread for everyone having a similar goal), I was able to make it work.

    Just one quick question about the examples before I close this issue: I basically would like to have the comfort of changing my PHY configuration with SysConfig, thus using the EasyLink API instead of using the RF driver API directly in the rfAudio example.

    So I could use either of these two approaches:

    1. Make SysConfig work in the rfAudioTx/Rx example
    2. Implement all of the features from rfAudioTx/Rx example into an EasyLink example project with the working SysConfig support

    In both cases I would still have to replace the RF driver commands (like RF_runCmd, RF_runScheduleCmd etc.) with the EasyLink commands. Is this a promising approach or is it too complex for a quick solution? And which one of these two solutions would be easier?

    Many thanks.

    Best regards,

    Alex

  • +1 in reply to Alexander Haß
    TI__Guru** 101450 points

    Hi Alex,

    Generally speaking, I would recommend to migrate the code to a newer SDK. However, I am not that familiar with these stacks and I would prefer an actual expert answers. May I kindly ask you to open a new thread to request guidance with the RF portion? 

    Best regards,