• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 100 subscribers
  • Views 378 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.

about LSP 2.0 (linux-mv-2.6.18 & dvsdk 2.00) issue

YHLShareware
Intellectual 830 points

Hi All,

I used that new kernel linux-mv-2.6.18 in LSP 2.0 package and used nfs as root filesystem what is included at the LSP 1.20 package on DM355 EVM,  I compiled the audio test program in DVSDK 2.0 and run it, I got "input/output error".

It seems that the audio driver can not work.  Please give me some clues. thanks very much.

 

BR,

Jeff

  • 0
    Prodigy 10 points

    Hi,

     

    This may be due to the change in the default audio driver support in DVSDk 2.0. It was OSS in previous version and now it is ALSA

     

    aswin

  • 0 in reply to SajiGopi
    Prodigy 105 points

    Did anyone find a solution to this? I think we are seeing the same issue.

  • 0
    TI__Expert 4010 points

    YHLShareware said:
    I used that new kernel linux-mv-2.6.18 in LSP 2.0 package and used nfs as root filesystem what is included at the LSP 1.20 package on DM355 EVM

     

    Why are you using the kernel from LSP 2.0 and the filesystem form LSP 1.20?  You may want to try installing everything from the same DVSDK package following the Getting Started Guide.

  • 0 in reply to David Meixner
    Prodigy 105 points

    We are using 2.6.18 and the DVSDK 2.X and were experiencing a similar issue. JPEG encoding crashing the audio sampling or audio sampling killing the encoding app depending what was running first. We found some information that suggested a change to the codecscfg used to build the codecs that get linked into our project. Below is the before and after, the thing that changed was the DMAN3.tccAllocationMaskL and DMAN3.tccAllocationMaskH. It seemed to resolve the issue but I want to understand why it worked so I know if we are headed for more issues later.

     

    /*
    *   For the 32-63 range, configure tccAllocationMaskH to exclude used channels
    *   JPEG Dec: {33-47, 52-57}
    *   JPEG Enc: {34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49}
    *   MPEG Dec: {32-63}
    *   MPEG Enc: {12, 13, 34, 35, 40,41,42,43,44,45,46,47,48,49,50,52,53,
    *              54,55,56,57,63}
    */
    DMAN3.tccAllocationMaskH = 0x0; /* everthing 32-63 hardcoded and unavailable */

    /* Give DMAN3 all lower TCCs except what's taken by Linux kernel and a Codec:
    * Based on the info from montavista: {2, 3, 8, 9, 26, 27, 30, 31}
    * and MPEG Enc taking up:            {12, 13}
    */
    DMAN3.tccAllocationMaskL = 0x33ffccf

     

    /*
    *   For the 32-63 range, configure tccAllocationMaskH to exclude used channels
    *   JPEG Dec: {33-47, 52-57}
    *   JPEG Enc: {34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49}
    *   MPEG Dec: {32-63}
    *   MPEG Enc: {12, 13, 34, 35, 40,41,42,43,44,45,46,47,48,49,50,52,53,
    *              54,55,56,57,63}
    */
    DMAN3.tccAllocationMaskH = 0xffffffff; /* everthing 32-63 hardcoded and unavailable */

    /* Give DMAN3 all lower TCCs except what's taken by Linux kernel and a Codec:
    * Based on the info from montavista: {2, 3, 8, 9, 26, 27, 30, 31}
    * and MPEG Enc taking up:            {12, 13}
    */
    DMAN3.tccAllocationMaskL = 0x0;