• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 860 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.

DM365: Interleaving order of channels swaps periodically

Tom Hanson
Intellectual 920 points

Odd, but true: the interleaving order of the right and left channels occasionally swaps.  I've been hearing it for weeks and I finally caught it on a data dump.

In the raw data buffer returned from DMAI's Sound_read(), usually the left channel is first, followed by the right channel.  Periodially, this will change!  Typically between invocations of an application but at least once while it was running.

Currently I'm using ALSA, previously I was using OSS.  This occurred in both scenarios.

Any suggestions for where to look?  I don't see any configurable options that should impact this.

TIA!

  • 0 in reply to Brad Griffis
    Intellectual 920 points

    Brad Griffis said:

    http://wiki.davincidsp.com/index.php?title=McBSP_Channel_Swapping

    Thanks!  That certainly sounds like the source of the problem.  A couple questions if I may just to remove any uncertainty:

    - The LSP 2.10 DaVinci Linux Audio Driver User's Guide seems to indicate that the interface is via McASP instead of McBSP.  Is this correct? if so, does the information in article still apply?

    - I'm working with an app that's loosely based on the DVEVM "encode" demo.  Can you point me to the init code for the McBSP?  Obviously one of the low-level libraries/drivers but assistance in locating the correct one would be greatly appreciated!

    Thx

  • 0 in reply to Tom Hanson
    TI__Guru*** 125430 points

    The DM365 does not have a McASP, only McBSP.  I looked in LSP 2.10 data manual and it has McBSP support for DM365.

    Sorry, I don't know off-hand where exactly to find that code.  Maybe someone else can point you to it, or else I'm sure you can find it with a little searching.

  • 0 in reply to Brad Griffis
    Intellectual 920 points

    Brad Griffis said:
    Sorry, I don't know off-hand where exactly to find that code

    I think I've found the code, but it's not being accessed.  If I'm reading things right, the configuration for the DM365 DVEVM board (dm365_evm_devices[] in linux-2.6.18_pro500/arch/arm/mach-davinci/board-dm365-evm.c) does not specify a McBSP device.  The equivalent structure for the H2 board does specify a McBSP device.

    This doesn't make sense to me, but then, I've wandered far afield from my area of expertise.

    Where should I look for help/documentation on how this should be configured???

     

    TIA!

  • 0 in reply to Tom Hanson
    TI__Guru*** 125430 points
    Is there something called "ASP" in there (not McASP)? It is more or less the same as mcbsp.
  • 0 in reply to Brad Griffis
    Intellectual 920 points

    Brad Griffis said:
    Is there something called "ASP" in there (not McASP)? It is more or less the same as mcbsp.

    Nope.  Here's the devices list:

    static struct platform_device *dm365_evm_devices[] __initdata = {
        &serial_device,
        &mmc0_device,
    #if 0
        &mmc1_device,
    #endif
        &nand_device,
        &rtc_device,
        &dm365_kp_device,
    };

    The closest thing I see is the serial device, but it's just setting up the UARTs.

    Is there some other path to McBSP initialization code?

  • 0 in reply to Brad Griffis
    Intellectual 920 points

    I found the information below on a TI website(http://wiki.davincidsp.com/index.php/PSP_Introduction_and_Product_FAQ).  The statement  "This patch also fixes the McBSP initialization sequence." seems promising. Problem is, I haven't found out how to determine what patch level I'm at, or what the contents of the patch are.  Where can I get this info?

     

    Project:

    Pro 4.0 PatchStream (Chronological)

     

     

     

    MontaVista Patch Level

    MontaVista Patch Name

    TI Reference #

    TI Patch name

    Description

    1687

    pro_arm_davinci_audio_mcbsp_init_fix_and_null_buf.patch

    34

    ti_davinci_mv_1_0_audio_mcbsp_init_fix_and_null_buf_implementation_034

    This patch implements the null buffer playback when McBSP has no data to process. This patch also fixes the McBSP initialization sequence.

     

     

  • 0 in reply to Tom Hanson
    TI__Guru*** 125430 points

    MV Pro 4.0 does not support DM365.  You need MV Pro 5.0 for that.

    I just did a quick search in MV Pro 5.0 (free download, no patches/updates applied) and found this file: ./montavista/pro/devkit/lsp/ti-davinci/linux-2.6.18_pro500/sound/soc/davinci/davinci-i2s-mcbsp.c.  I'm not sure if it's even the right one, but it's at least McBSP-related!

    I recommend starting a separate thread for the purpose of finding the McBSP initialization code so that some of our more Linux-savvy community members can help out.  Once you have the code in front of you we could continue this discussion.

  • 0 in reply to Tom Hanson
    Intellectual 920 points

    There appears to be a patch in the works for DM365 McBSP initialization " [03/46] Davinci: DM365: Add platform device for McBSP " (http://patchwork.kernel.org/patch/54362/).

    I'm not sure that it addresses the issues raised in the article referenced above.  I'm not seeing anything that looks like a polling loop to detect frame synch, but I could be mistaken.

    Is there a way to determine the timeline for this patch becoming available?