Audio underrun/overrun

Hi Kevin,

Thanks for your post.

In my understanding, I do see error handling in the code when it tries to recliam full buffer from the input stream or empty buffer from the output stream to be reused. It checks the status of IOM_COMPLETED and by evaluating this, it throws error through System_printf through function call Audio_echo_Task() in audioSample_io.c source file path as below.

~\pdk_C6748_2_0_0_0\biospsp_03_00_01_00\drivers\examples\evm6748\audio\src\audioSample_io.c

------------------------------------------------------------------------------------------------------

        /* Reclaim full buffer from the input stream                          */
        status = GIO_reclaim(inStream, (Ptr *)&rcv, NULL, NULL); 

        /* Reclaim full buffer from the input stream                          */
        if (status != IOM_COMPLETED)
        {
            System_printf("\r\nError reclaiming full buffer from the input stream\n");
        }

        /* Reclaim empty buffer from the output stream to be reused           */
        status = GIO_reclaim(outStream, (Ptr *)&xmt, NULL, NULL);
        if (status != IOM_COMPLETED)
        {
            System_printf("\r\nError reclaiming empty buffer from the output stream\n");
        }

------------------------------------------------------------------------------------------------------------

Also, I believe LoopJob feature is also handled through the macro #ifdef Mcasp_LOOPJOB_ENABLED in the mcasp driver code in the below path:

~\pdk_C6748_2_0_0_0\biospsp_03_00_01_00\drivers\mcasp\src\Mcasp_ioctl.c

Kindly clarify your question to a better extent of providing more details on the same.

Thanks & regards,

Sivaraj K

These System_printf() reports occur if there is some internal error reported by the driver. If there is no buffer to reclaim, GIO_reclaim() will block until there is a buffer available and no error will occur.

The condition I would like to detect is if the while loop in this example takes too long to execute either because you've replaced the memcpy() in the middle with something more interesting or because of other higher-priority tasks and interrupts that suspend execution of this loop.

In these cases you may not get to servicing the input channel before all issued buffers are filled and you may not get to servicing the output channel before all issued buffers are transmitted. If no buffers are available, the input channel will discard input data and the output channel will transmit silence, clearly a bad thing for many applications, but there is no indication given to the application that this has happened.

HI Kevin,

Thanks for your update.

If the input channel discards input data or the output channel transmits silence, there are buffer underrun/overrun flags can be triggered, if XRBUF has not yet been written with new data since the last time the transfer occurred, the transmit state machine sets the XUNDRN flag and likewise, the receive state machince sets the ROVRRN flag.

Could you please send us the memory dump of the McASP registers and EDMA while you experience the issue which you have posted above?

Thanks & regards,

Sivaraj K

I assume you're talking about transfer overrun and underrun detection features in the McASP hardware that can flag failure of DMA to keep pace with data. My question is actually about support for reporting buffer overrun and underrun conditions in the SYS/BIOS PSP driver for McASP. I think we're talking about different things here. If not, please let me know how I can read the flags you describe through the SYS/BIOS GIO interface.

Hi Kevin,

Thanks for your update.

Please refer Sections 23.2.4.7.2 (Underrun in Tx.) & 23.2.4.7.3 (Overrun in Rx.) in the C6748 TRM as below for more details on the same :

http://www.ti.com/lit/ug/spruh79a/spruh79a.pdf

In the above doc., you shall trigger the receiver overrun interrupt enable bit thru. RINTCTL register and you shall check the status of Receiver overrun by reading thru. ROVRN flag in RSTAT register. Please refer Section 23.3.20 & 23.2.21 for more details on these registers from the above TRM doc.

Likewise, you shall trigger XUNDRN transmitter underrun interrupt enable bit thru. XINTCTL register and check the status of transmitter underrun thru. XUNDRN flag in XSTAT register. Please refer Sections 23.3.32 & 23.3.33 for the samefrom the same TRM doc. mentioned above.

Thanks & regards,

Sivaraj K

I can see now that we are definitely talking about two different things. My question is about the SYS/BIOS driver for McASP. You are giving me information about the hardware that would be useful if I were writing my own driver. I am not.

It would be nice if the SYS/BIOS McASP driver would report the ROVRN and XUNDRN conditions you describe and perhaps it does. But that's not my question either.

As described in http://downloads.ti.com/dsps/dsps_registered_sw/sdo_sb/targetcontent/psp/bios_psp/1.30.xx/1.30.00.05/C6748/C6748_BIOSPSP_Userguide.pdf and http://www.ti.com/lit/ug/spruex3m/spruex3m.pdf, you deliver buffers to the McASP driver with GIO_Issue(). If the application does not deliver buffers fast enough, the driver will discard receive data or transmit silence. This is not an overrun or underrun on a hardware level but at a software level in the driver. As far as I can tell from the documentation and the source code for the driver, there is no indication given to the application when this happens. I am either mistaken or this is a significant piece of missing functionality or is there some other way an application can know whether it is keeping up with the audio interface?

Hi Kevin,

I do understand that, your question is about the Sys/Bios driver for McASP and again we are clear that, the underrun or overrun issue is at software level and not on hardware and even i have provided you the information how to trigger underrun/overrun flags in Rx/Tx McASP serializers only in the context of software point. I do apologise for any misinterpretation, if any.

I am surprised that there wouldn't any missing functionality which you say like, discarding receive data or transmit silence because it would give you an proper indication if you debug the code thru. the ccs register window by which you shall be able to access the status of McASP control registers like RINTCTL, RSTAT in the Rx. side, it would trigger you the receive overrun interrupt via ROVRN flag if the appropriate bit is enabled and likewise, it would trigger on the tx. side through XUNRRUN flag, if the tx. buffer is not filled with any new data since the last tx. transfer. By this way, it is evident that, it wouldn't miss/discard any Rx. data else, it would enable the ROVRN flag status in the Rx. buffer and in a similar way, the Tx. wouldn't tranmit any null data else, it would stimulate the Tx. buffer to XUNDRUN state and the appropriate flag would be enbled in the ccs register window thru. appropriate McASP control registers.

If you think the above mentioned issue is still there in your case, please provide us the memory dump of the McASP registers, so that, it would be more evident to look into issue insignt and provide you more clarity on the same. It would also help us to analyse the issue in a better way.

Thanks & regards,

Sivaraj K

The overrun/underrun I am immediately concerned about does not happen in McASP hardware. The ROVRN and XUNDRN flags are set if the DMA does not service McASP hardware in time. I have no indication that there is a problem here.

Where I do have a problem is that once a receive buffer is full, if there is not another one available for the driver to use, it will direct the DMA to the "LoopJob" buffer. There is no indication to the application from the driver that this has happened.

Similarly if the application does not supply new transmit buffers quickly enough, once the last buffer has been emptied, transmit DMA is sourced from a different "LoopJob" buffer and silence is transmitted. This is the failsafe action that we want to happen but my issue is that there is no means for the application to learn that it has missed the deadline and the continuous flow of audio has been interrupted.