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

tangch ch
Prodigy 190 points
Other Parts Discussed in Thread: PCM1808

Hello everyone,

        Recently I met an problem with mcasp audio capture. The appearance is that when occur overrun, mcasp will capture some error data from PCM1808 . And this data is generated by PCM1808, mcasp just catpured them. When I go through pcm1808 datasheet, I found that pcm1808 will "Power Down and Reset by Halting System Clock".

In functuin snd_pcm_update_state int file sound/core/pcm_lib.c, 

                                          if (avail >= runtime->stop_threshold) {
                                                  xrun(substream);
                                                  return -EPIPE;
                                          }

when application thread can't send or get audio data from mcasp, kernel will raise an EPIPE signal to alsa lib, that is overrun.

In this case, mcasp will be stopped, and stopped the AFSR/X clock, and then  PCM1808 will reset and then generate than pulse.

How to fix this problem? How to avoid reset PCM1808, because we do not want to capture these error data .

Thank you everyone

  • 0
    TI__Guru**** 170625 points
    Hi Tangch,

    Which problem you need to fix? And is this problem in DM814x McASP or in PCM1808? What is the software release you are using?

    Regards,
    Pavel
  • 0 in reply to Pavel Botev
    Prodigy 190 points
    Hi Pavel,
    Sorry for my careless, my linux kernel is linux-04.04.00.01. The problem is that how can mcasp supply AFSR/X clock continuously even when overrun occur. In my opinion, PCM1808 is reset because of mcasp stop supply AFSR/X clock when overrun occur.
  • 0 in reply to tangch ch
    TI__Guru**** 170625 points

    Tangch,

    Do you use EZSDK 5.05.02.00 which comes with linux-2.6.37-psp04.04.00.01?

    Let me confirm my understanding. DM814x McASP is providing the AFSR/X clock to PCM1808. PCM1808 is providing the audio data to McASP. At some time audio overrun occur and McASP will stop capture audio data from PCM1808 and will stop provide AFSR/X clock to PCM1808. And you do not want to fix the overrun, but you want to keep McASP provide the AFSR/X clock to PCM1808. Is that correct?

    Regards,

    Pavel

  • 0 in reply to Pavel Botev
    Prodigy 190 points
    Hi Pavel,
    Do you use EZSDK 5.05.02.00 which comes with linux-2.6.37-psp04.04.00.01?
    -------Yes
    Is that correct?
    --------Yes, is correct.
    Is better to fix overrun problem. (In my opinion, overrun can't be avoid when CPU is busy and the capture/playback thread can't be scheduled in time.)
  • 0 in reply to tangch ch
    TI__Guru**** 170625 points
    Tangch,

    Can you provide me the values you have in the below bits (get these from user space):

    AMUTE[5] ROVRN
    RINTCTL[0] ROVRN

    Why do you think McASP will stop to drive the AFSR/X clock when overrun occur? Do you check the AFSR/X pins with oscilloscope?

    Regards,
    Pavel
  • 0 in reply to Pavel Botev
    Prodigy 190 points
    Hi Pavel,
    Can you provide me the values you have in the below bits (get these from user space):

    AMUTE[5] ROVRN --------------------0
    RINTCTL[0] ROVRN-------------------0

    Why do you think McASP will stop to drive the AFSR/X clock when overrun occur? Do you check the AFSR/X pins with oscilloscope?
    --------------Yes

    Thank you
  • 0 in reply to tangch ch
    TI__Guru**** 170625 points
    Tangch,

    Can you provide McASP register dump before and after overrun occur? The below registers are needed:

    PDIR, PFUNC, PDOUT, PDIN, PDSET, PDCLR, AFSRCTL, AFSXCTL, GBLCTL, RGBLCTL, XGBLCTL, AMUTE, AFSRCTL, AFSXCTL, RINTCTL, XINTCTL, RSTAT, XSTAT

    Regards,
    Pavel
  • 0 in reply to Pavel Botev
    Prodigy 190 points

    Hi Pavel,

        I add the debug info in function davinci_mcasp_trigger, 

        case SNDRV_PCM_TRIGGER_STOP:
        case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
        if(substream->stream == SNDRV_PCM_STREAM_CAPTURE)
        {
            printk("befor davinci_mcasp_stop \n");
            dump_mcasp_regs(dev);
        }
        davinci_mcasp_stop(dev, substream->stream);
        if(substream->stream == SNDRV_PCM_STREAM_CAPTURE)
        {
            printk("after davinci_mcasp_stop \n");
            dump_mcasp_regs(dev);
        }
        break;

    when occur overrun, the debug info is following:

    befor davinci_mcasp_stop
    PFUNC(0xFA038010)=0x00000000
    PDIR(0xFA038014)=0xFC000010
    PDOUT(0xFA038018)=0x00000000
    PDIN(0xFA03801C)=0xB0000014
    PDCLR(0xFA038020)=0x00000000
    AFSRCTL(0xFA03806C)=0x00000113
    AFSXCTL(0xFA0380AC)=0x00000113
    GBLCTL(0xFA038044)=0x00001F1F
    RGBLCTL(0xFA038060)=0x00001F1F
    XGBLCTL(0xFA0380A0)=0x00001F1F
    AMUTE(0xFA038048)=0x00000000
    RINTCTL(0xFA03807C)=0x00000000
    XINTCTL(0xFA0380BC)=0x00000000
    RSTAT(0xFA038080)=0x0000017D
    XSTAT(0xFA0380C0)=0x00000154

    davinci_mcasp_stop called, capture
    after davinci_mcasp_stop
    PFUNC(0xFA038010)=0x00000000
    PDIR(0xFA038014)=0xFC000010
    PDOUT(0xFA038018)=0x00000000
    PDIN(0xFA03801C)=0x80000014
    PDCLR(0xFA038020)=0x00000000
    AFSRCTL(0xFA03806C)=0x00000113
    AFSXCTL(0xFA0380AC)=0x00000113
    GBLCTL(0xFA038044)=0x00001F00
    RGBLCTL(0xFA038060)=0x00001F00
    XGBLCTL(0xFA0380A0)=0x00001F00
    AMUTE(0xFA038048)=0x00000000
    RINTCTL(0xFA03807C)=0x00000000
    XINTCTL(0xFA0380BC)=0x00000000
    RSTAT(0xFA038080)=0x00000104
    XSTAT(0xFA0380C0)=0x0000015C

    Thks

  • 0 in reply to tangch ch
    TI__Guru**** 170625 points
    Tangch,

    The AFSR signal is stopped by the mcasp_stop_rx(dev) function, it manipulates register RGBLCTL.

    Regards,
    Pavel