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.

  • Resolved

Not worked Mcasp driver with smaller samples per frame configuration - aduioSample from PSP ver 02_10_01

Hi,

I'm now using audioSample from pspdrivers_02_10_01 on DA830EVM and it looks working with default configuration.

When I changed the sample app with following configurations, I saw McASP underrun/overrun error and then, program was terminated.

  1. 4 samples per frame
  2. 48khz input/output configuration
  3. Cache optimization - 32k L1P/L1D cache, 128k L2 cache
  4. Using IRAM application buffer/loopJobBuffer

Please note I saw correct behavior if I use 8 samples per frame rather than 4. I also used release build option for both app and config app, but the result was same - not worked.

Now my questions are :

  1. Is 4 samples per frame configuration reasonable to work audioSample (using dma driven option in mcasp driver) ?
  2. Is it possible to use interrupt driven option in Mcasp driver ? I just reviewed mcasp driver code, but it looked the implementation for cpu driven is not enough to work, for example, there is no reasonable implementation in submit call handler if the mode is interrupt driven option.

Best Regards,

kawada

 

  • Kawada,

    Naoki kawada
    Is 4 samples per frame configuration reasonable to work audioSample (using dma driven option in mcasp driver) ?

    Could you please send us the McASP configuration done in the Sample application for 4 samples per frame and the 8 samples per frame?

    Could you please check if there is any error is set in case of 4 samples per frame?

    Naoki kawada
    Is it possible to use interrupt driven option in Mcasp driver ? I just reviewed mcasp driver code, but it looked the implementation for cpu driven is not enough to work, for example, there is no reasonable implementation in submit call handler if the mode is interrupt driven option.

    No, we donot support interrupt mode of operation. The interrupt ISR is registered only to handle the error interrupts.

    Thanks and Regards,

    Sandeep K

    Does this help with your question? If not, please send back more information. If it answers your question, please click the  Verify Answer  button below

  • In reply to Sandeep Krishnaswamy:

    Hi Sandeep,

    Thanks for your help.

    I've attached the code - audioSample_io.c - for 4samples per channel @48khz. You will be able to recreate the issue just by replacing the original code. With default gel file, You will see mcasp underrun or overrun error message on console window. As I mentioned before, I had tried some optimization for memory layout, but the problem was still there. To change 8sample base system, please change the definition , 4 to 8, on line 90.

    >>Could you please check if there is any error is set in case of 4 samples per frame?

    The overrun/underrun error I saw was raised from mcasp error interrupt.

    >>No, we donot support interrupt mode of operation. The interrupt ISR is registered only to handle the error interrupts.

    Ok. I understand... I'm wondering if  we may not be able to use McASP PSP driver for audio low latency system (upto 4samples) because of EDMA overhead. If this is true, we have to consider about sample-based mcasp driver.

    audioSample_io.c
  • In reply to Naoki Kawada:

    Hi Kawada,

    First we need to consider that the data length provided to the McASP is very less, which is only 4 samples. In real time it will be in terms of KB.

    Secondly,  the McASP driver algorithm takes some time to handle the EDMA completion interrupt. Only two EDMA link channels are programmed at a time for EDMA, and if second link (packet) is completed before the completion of first link's (packet) EDMA completion handler, there could be an under run error. This will not be observed if the sampe size is more.

    So it is advisible to use the sample size greater than 8 samples or so.

    Thanks and Regards,

    Sandeep K

    Does this help with your question? If not, please send back more information. If it answers your question, please click the  Verify Answer  button below

  • In reply to Sandeep Krishnaswamy:

    Hi Sandeep,

    As for your second consideration, I don't agree with you. Your consideration is for interrupt miss for EDMA transfer completion, right ? Even if CPU misses real time, McASP driver should go to its "loop job", which it is EDMA's dummy transfer from loop job buffer. If application is completely delayed to submit application buffer (i.e.,real time miss), for tx case, McASP would go into its loop job in order to avoid underrun error.  So, underrun error should not be caused by CPU real time miss. Underrun/Overrun will happen only when EDMA activity is completely delayed to put/retrieve audio data to/from McASP DAT PORT until McASP completes to shift out/in audio data from XSR (McASP's shift register in serializer ). So, as for underrun/overrun error, we need to consider why EDMA is delayed ...  

    What do you think of this ?

    Fyi, I have moved both Application buffer and loop job buffer to IRAM (these are on SDRAM by default) in order to delete EMIF bus bottom neck, To do this, it would be easier for EDMA to move data - but overrun/underrun was still observed. Also, I've a bit changed EDMA RDRATE register, the situation was same.

    Best Regards,

    kawada


     

  • In reply to Naoki Kawada:

    Hi Kawada,

    Naoki kawada
    As for your second consideration, I don't agree with you. Your consideration is for interrupt miss for EDMA transfer completion, right ? Even if CPU misses real time, McASP driver should go to its "loop job", which it is EDMA's dummy transfer from loop job buffer. If application is completely delayed to submit application buffer (i.e.,real time miss), for tx case, McASP would go into its loop job in order to avoid underrun error.  So, underrun error should not be caused by CPU real time miss. Underrun/Overrun will happen only when EDMA activity is completely delayed to put/retrieve audio data to/from McASP DAT PORT until McASP completes to shift out/in audio data from XSR (McASP's shift register in serializer ). So, as for underrun/overrun error, we need to consider why EDMA is delayed ...  

    According to my observation, by the time the McASP driver completes the EDMA interrupt handling for the first packet, if secong packet is also completed (since only 4 samples are there), then there is no param set with the EDMA (not even the loopjob) to process and McASP clock is stil running may give an underun error. Do you agree? 

    Thanks and Regards,

    Sandeep K

    Does this help with your question? If not, please send back more information. If it answers your question, please click the  Verify Answer  button below

  • In reply to Sandeep Krishnaswamy:

    Hi Sandeep,

    Thank you for the comments on this.

    McASP driver isr (for edma transfer completion) updates the link param for next process. If driver also updates param "link addr" information in ISR, I agree with you, but in the driver code, the link addr itself has been configured at Mcasp_open. That means link params would be configured with something valid value (but not correct for current process buffer because dirver has missed ISR) at underrun/overrun condition.  I seem driver continues its edma job with the configuration for previous application buffers even when driver has missed its isr.

    Can you elaborate a bit on this - why underrun/overrun can happen if driver misses its isr.

    Best Regards,

    kawada

     

  • In reply to Naoki Kawada:

    Kawada,

    Initially, when we open the McASP, two link params are taken from the EDMA which is being used in the McASP. At the beggining, there will not be any packet submitted to the McASP. So only one link param will be there (which is loopjob) and will be linked to itself.

    When we start the audio sample application, totally four packets will be queued in the driver (two in the floating queue and two in the pending queue). So loopjob will be replaced with the valid buffer provided by the application.

    Now, if we get an EDMA callback for the first packet and before handling it, if next packet is also completed by the EDMA (since the sample size is very less), then there is a chance of having no data with the EDMA (since we have not got the time to configure the valid buffer or the loopjob) to transfer. This scenario may cause the underrun error.   

    Thanks and Regards,

    Sandeep K

    Does this help with your question? If not, please send back more information. If it answers your question, please click the  Verify Answer  button below

  • In reply to Sandeep Krishnaswamy:

    Hi Sandeep,

    I'm sorry for you to asking so many things , but I can't still understand your point correctly. I think I roughly understand the driver architecture itself. Could you please see slide 7 ? That is my question.

    If your driver does not support lower than 8 samples per frame, it can't be helped (we (my customer) may need to consider not to use your psp). but I would like to know the reason correctly.

    Also, this is just for your information, there are some bugs in the driver code, which these are not related to this underrun/overrun issue. Please see slide 8. If these are correct, I would like you to feedback them to your driver team.

    Best Regards,

    kawada

    mcasp.ppt
  • In reply to Naoki Kawada:

    Kawada,

    Sorry for the delayed response.

    First of all, a nice presentation :) Thank you.

    I have gone through the ppt, as you have mentioned in the ppt, it is logical to say that the edma miss should not result in the underrun error. Otherwise it should have taken the stale data. When i observed the link params, all the fields are intact at the time of underrun error, which means the edma configuration is proper.

    I suspect some kind of race condition is resulting in underrun error, but at this moment, I am not able to pin point the root cause. The big problem is, if i put breakpoint to debug this, it is very difficult to reproduce the issue.

    BTW, I have observed that, if  i change the codec sampling frequency to 96KHz, the 4 sample is working fine. Can you test this out?

     

     

     

     

     

     

     

     

     

     

    The change looks like,(in audioSample_io.c file)

     Audio_ChannelConfig audioIfChanDefaultInfo[2]=
     {
           /* channel 0 (RX) */
          &mcasp_chanparam[0],

          /* channel params */
          {
                /* codec [0] */
                {
                       // 48000, /* sampling rate */
                       96000,   /* sampling rate */
                       30,
                       /* gain */
                       0x00,
                       0x00
                }
           },

           /* channel 1 (TX) */
          &mcasp_chanparam[1],
      
           /* channel params */
           {
                 /* codec [0] */
                 {
                       // 48000, /* sampling rate */
                       96000,  /* sampling rate */
                       70,
                      /* gain */
                      0x00,
                      0x00
                 }
           }
     };

     

    Thanks and Regards,

    Sandeep K

    Does this help with your question? If not, please send back more information. If it answers your question, please click the  Verify Answer  button below

  • In reply to Sandeep Krishnaswamy:

    Hi Sandeep,

    Thank you for the reply, and I'm glad you tried to understand me :)

    Here is my further observations. The default psp library is being built with "-mi10 -mo" compile options. I rebuilt psp with "-mi10 -mo -o3", the underrun/overrun error disapeared. But I still saw noisy output using 4sample configurations. The reason was because the interrupts have being missed and CPU and EDMA HW was out of sync completely.

    I tried to measure CPU/Thread load by using RTA (CCSv4) for 8 sample configurations and then I found it takes about 95% CPU load for audio echo !! So, 4 samples configurations is no way to work correctly even if we work around underrun/overrun error... Of cause, it should not work for 96khz.

    For your information, I've applied some optimizations and I could reduce CPU load to 65% (30% reduction):

    1. Cache configurations : L1D=32Kbytes, L1P=32Kbytes, L2 = 128Kbytes
    2. Move critical sections to IRAM (io buffers, vector table, stack, task's stack )
    3. Disable cache handling in McASP driver (because I've moved io buffers to IRAM)
    4. Build related library with -o3 compile option (ipc pacakge, psp driver for mcasp
    5. Using ROM BIOS

    But in general, I think user would like to use more MIPS for their application. 65% is still too high for framework.

    I think more than 16 samples may be reasonable configuration, I saw about 30% Cpu load with the above optimizations for 16 samples configurations

    What do you think of this ? If you agree with me, I would like to close this thread.

    Best Regards,

    kawada

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.