• Locked Locked
  • Replies 8 replies
  • Subscribers 99 subscribers
  • Views 968 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.

Audio Architecture on OMAP3530

fabrice saadoun
Prodigy 220 points
Other Parts Discussed in Thread: OMAP3530

Hello,

We think about implementating an Audio line up (codecs, echo canceler, noise supressor, etc...) on an OMAP3530 platform for VOIP purpose.

I understand that for video the DSP (IVA2+) should be used because of the amount of data and algorithm processing.

For Audio I am not sure how DSP can provide a strong help to the HOST (ARM) in terms of algorithm computation since the ARM is a quite strong processor (600Mhz).

Actually we would like not to use the DSP bridge (DSPLink) which can simplify the SW architecture (no ARM - DSP communication is needed).

So if we only use the ARM to do the job the architecture will be:

Microphone -> McBsp -> Audio Driver-> Audio lineup -> Wifi                    - for uplink

Wifi -> Audio lineup -> Audio driver ->McBsp-> Speakerphone                - for downlink

Questions:

Our only doubt is that how can we be sure that the ARM will be able to support that process (here a Windows Mobile will be used as an OS)?

Do you know any product that is using this type of architecture?

What does the IVA2+ include in terms of audio processing optimization that is susceptible to help us?

Thanks for the help.

Fabrice.

 

  • TI__Mastermind 28055 points

    Fabrice

    From a hardware perspective the low bit rates should not pose a problem for the ARM. However I'm not familair with the codec requirements so I'll defer to the s/w team to respond.

      Paul.

  • TI__Expert 3710 points

    To answer this question accurately, you have to think from overall system perspective. It does not matter that ARM is 600 MHz - you have to determine what else is running on ARM (in worst case) and how many MIPS are free for Audio processing. Also, what audio codecs are you planning to support - different codecs have different MIPS requirements. Apart from codec, AER (Echo cancellation) is another big piece. How sophisticated of an algorithm do you have and what are its processing/latency requirements. Does the product have speaker phone - this may impact AER performance and requirements. In other words, how you split the processing load would depend upon what you are trying to build. If this is multimedia gadget where voice just as an auxiliary feature with average quality, you may be able to squeeze everything on ARM. On the other had, if this is something like IP phone with sophisticated UI running on ARM and great voice quality, you will probably have to leverage DSP as well

    thanks

    Atul Verma

  • in reply to Atul Verma
    Prodigy 220 points

    Hi Atul,

    Thank you for you inputs. It seems that it is less risky to use the DSP in our case since voice is an essential module in our product. I would like to add some questions concerning SW architecture if you don't mind.

    1 - What does the IVA2+ include in terms of audio processing optimization that is susceptible to help us? (it was in the email before).

    2 - We already have a working SW (HOST + DSP) running on an OMAP2420 and using the previous bridge version + DSP/BIOS+DASF (TI audio Framework).

          a - How complicate it is to port that SW to an architecture including the new TI bridge (DSPLink)?

          b - Are the 2 bridges compatible?

          c - Is DSPLink working on a Node/Issue/Reclaim concept?

          d - Can we still use the DASF on top of DSP/BIOS OS?

          e - Will it be complicate to port the audio process from C55x to C64x+ (C and assembly code)?

    Thank you.

    Fabrice Saadoun.

  • in reply to fabrice saadoun
    TI__Expert 4930 points

    Fabrice,

    Can you give more details of the previous bridge version? Do you mean an older version of DSPLink? This will enable me to answer questions a and b.

    c. DSPLink has a IPC called CHNL which does support Issue/Reclaim model of DSP/BIOS.

    Regarding d and e I will let others answer.

    Deepali

  • in reply to fabrice saadoun
    TI__Expert 3710 points

    Hello Fabrice,

        I don't think I can answer all your questions (since I am not familiar with your SW or your current architecture) but here is what comes to mind:

    1. Regarding IVA, there are no built in audio processing optimizations I am aware of but obviously the instruction set helps in implementing algorithms (such as filters, FFTs, up/down scalars etc)  that are typically employed in media processing (audio, video, speech) and echo cancellation.  This, coupled with hw resources (such as DMA and TDM bus, interrupts) together with efficient OS (BIOS) makes for a tight and efficient implementation.

    2. There will be work involved in porting your current implementation running on Bridge to Codec Engine/DSP Link framework - how much I don't know - will depend upon your skill level and familiarity with these technologies.

    3. Regarding 2(e), you should be able to recompile your pure C code from C55x and use it on C64x without much trouble - code dealing with hw resources will have to be ported though - don't know how much you have. For optimized assembly code on C55x you will have to port it over to C64x (if you have corresponding C code, as a first step just compile that and see if it meets your time/processing requirements - if not, then go to second step of optimization)

    thanks

    Atul

     

  • in reply to Deepali Uppal
    Prodigy 220 points

    Deepali,

    I don't which type of bridge it is. I know that one of our company's team ported that bridge from Linux to WinCE and from OMAP1710 to OMAP2420. That work has been done around 2005. Please see also below this bridge architecture according to our team investigattion (code reverse engineering). All this can give you an idea of what bridge we are using:

    Please tell me if you need more details.

    Regards,

    Fabrice.

  • in reply to fabrice saadoun
    Prodigy 220 points

    Deepali,

    Can you please answer  questions a and b with the details I gave you previously?

    Thanks,

    Fabrice

  • in reply to fabrice saadoun
    TI__Expert 4930 points

    Fabrice,

    This looks like DSP Bridge to me. See here http://www.omappedia.org/wiki/DSPBridge_Project

    This is different from DSPLink and is already available on OMAP3530 plus Linux

          a - How complicate it is to port that SW to an architecture including the new TI bridge (DSPLink)?

    DSPBridge is different from DSPLink. See here: http://linux.omap.com/pipermail/linux-omap-open-source/2007-May/009850.html Would it not be better for you to use the existing architecture?

          b - Are the 2 bridges compatible?

    No, DSPLink is different from DSPBridge. See here for a similar email chain http://www.spinics.net/lists/linux-omap/msg34791.html

    .

    Deepali