• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 1578 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.

USB Audio Class Device on C674x

Cliff Elion
Prodigy 225 points

Other Parts Discussed in Thread: OMAP-L138, OMAP-L137

Is there any application example for Audio Device Class.

I have seen several posts about this with no resolution - one of them referred to the BIOSUSB, but that only supports Mass Storage Device Class and HID class. 

 

Thanks,

 

Cliff

  • 0
    TI__Guru*** 125430 points

    Cliff,

    Sorry, this is not available for the DSP.  Supported USB modes can be found in the User Guide for PSP 1.30.01 for the c6748:

    http://software-dl.ti.com/dsps/dsps_public_sw/psp/BIOSPSP/01_30_01/index_FDS.html

    We have the OMAP-L138 which is pin for pin compatible with the c6748.  With that device you can leverage the rich ARM/Linux ecosystem where the USB isochronous driver and many others are available for use.  This is detailed in the Linux PSP Features and Performance Guide:

    http://processors.wiki.ti.com/index.php/DaVinci_PSP_03.20.00.14_Device_Driver_Features_and_Performance_Guide#USB_Isochronous_Driver

    Best regards,
    Brad

  • 0
    Guru 26430 points

    Moving from C674x to OMAP-L13x has some side effects:
    - Second processor, more power consumption and heat
    - More expensive part, eg for BZCE3 part from 14.40 to 17.10
    - A DSP only solution could be shoe-horned into on-board memory. Linux needs as much SD-RAM as you can include. More cost, more board space, more PCB complexity, more risk, more power consumption.
    - Need two development environments. Building Linux generally needs another Linux environment. The tools for the DSP seem to work best on Windows. Ideally you need two host machines, Linux and Windows.
    - Learning to develop Linux is not trivial. Add in more development time. Add in U-boot and it gets worse.
    - Inter-processor communication is required. Additional development time, complexity and risk.
    - JTAG interface to two devices on the same chain can cause some problems with debugger pods. Special care required. More cost. More time.

    The large amount of Linux based code is a very real feature that can justify all the extra time, code, complexity and risk.

     

  • 0 in reply to Norman Wong
    TI__Guru*** 125430 points

    Norman,

    You're right -- it's certainly not trivial and Linux will definitely require external memory.  On that note if you decide to go down this path you might also consider the OMAP-L138.  It supports DDR2 so your system cost may actually come out lower than using the OMAP-L137 since SDRAM has gotten more expensive lately.

    In terms of a host OS for development you should now be able to do everything from Linux.  CCS 5.1 will install and run in Linux and has support for JTAG emulation as well.  So you should be able to do ARM and DSP development using CCS in Linux.  (I'm excited about this because now I can do everything from Linux rather than constantly switching back and forth.)

    Best of luck with your design.

    Brad

  • 0 in reply to Brad Griffis
    Prodigy 225 points

    Brad/Norman,

    Thanks for the overview - the system cost and overhead of Linux is a little daunting for our application - this is a low-cost, low-power audio processor.  ... I understand the benefits of Linux, but it seems to me that already having the HID and MSD drivers available in BIOSUSB it would be feasible to implement AudioStreaming Class for someone who has the experience and source code.

    Two things come to mind:
    1. the Linux implementation of AudioStreaming has to access the same hardware on the chip. Would it be possible to get that driver source and attempt to compile it for the DSP?
    2. do you think that there may be interest at TI to implement this?.

     

    Cliff Elion

  • 0 in reply to Cliff Elion
    TI__Guru*** 125430 points

    Cliff Elion said:
    1. the Linux implementation of AudioStreaming has to access the same hardware on the chip. Would it be possible to get that driver source and attempt to compile it for the DSP?

    All the Linux source code is covered by GPLv2, so if you use that code then your project will also become GPLv2.  That's probably not what you want.

    Cliff Elion said:
    2. do you think that there may be interest at TI to implement this?.

    Interest, yes.  Resources, no.  Maybe down the road we will do the work for another device and be able to backport to 6748, but I don't see it happening any time soon.  I think your choices ultimately come down to:

    Cliff Elion said:
    the system cost and overhead of Linux is a little daunting for our application - this is a low-cost, low-power audio processor.

    Maybe you could use a cheaper version like the c6742 plus a TUSB3200A?

  • 0 in reply to Brad Griffis
    Prodigy 225 points

    OK ... good advice ... one last question. Do you know if the TUSB3200A USB hardware is similar in any way to the hardware in the c674x? .... could this code be ported easily?

     

    Cliff

  • 0 in reply to Cliff Elion
    TI__Guru*** 125430 points

    I did a little asking around and it looks like they're pretty different under the hood, i.e. no way to re-use USB code from the TUSB3200A in the c6748.

  • 0 in reply to Brad Griffis
    Prodigy 225 points

    OK .. thanks Brad! will consider using the TUSB3200A for now. Potentially we can implement the native driver later. For my reference, is the Audio Class driver included in the MontalVista Linux that comes with the Eval Board?

     

    Thanks,

     

    Cliff

  • 0 in reply to Cliff Elion
    TI__Guru*** 125430 points

    The "normal" way you would use the TUSB3200A would be to connect an audio codec to the C-Port and then let the TUSB3200A handle the USB connection to the PC or whatever it's talking to.  So I believe in your case you will put a c6748 DSP in between the audio codec and the TUSB3200A.

    Depending on how much processing you need to do, perhaps you could replace the 6748+codec with a single AIC3254.  The AIC3254 contains a "mini DSP" for doing some signal processing.  So in that case your system would just be TUSB3200A + AIC3254.  If you need more heavy duty signal processing, then TUSB3200A + c6748 + codec would be a great option.

    Good luck on your design!  Hopefully one of these solutions will fit well.

    Best regards,

    Brad

  • 0 in reply to Brad Griffis
    Prodigy 225 points

    Thanks Brad --- will look at the AIC ... but more than likely it will be the C674x.

     

    Cliff

  • 0 in reply to Cliff Elion
    Guru 26430 points

    I would guess you'd prefer the C674x series for the floating point. A couple of options if you reconsider a C674x with on-board USB (Mentor) controller.

    BIOSUSB is written by Jungo. They offer an audio class:
    http://www.jungo.com/st/embedded_usb_audio.html
    I don't know the cost. My project managers usually kill this option when they find out.

    BIOSUSB is, in theory, configurable and extensible. The lack of documentation and examples makes it very difficult to do so. So far the best documentation is in this thread:
    http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/t/111627.aspx
    You would be esentially implementing what Jungo is selling, an audio class on top of the core and driver layers.

    The Montavista Linux shipped with the Eval boards are very old, 2.6.18. I don't have access to dev box to check but I doubt audio class gadget drivers would be included. They are definitely on the newer versions included with TI's DVSDK.
    http://arago-project.org/git/projects/?p=linux-davinci.git;a=tree
    drivers/usb/gadget/audio.c
    drivers/usb/gadget/f_audio.c
    drivers/usb/gadget/u_audio.c
    drivers/usb/musb/* - host and device driver for Mentor USB OTG controller