Omap l137 audio buffers

Project base line
https://www.dropbox.com/sh/7trrdy0ylioq1n6/pfAzidGyEW?m


Project: OMAPL137 Audio in/out using McASP and DMA to send /receive Audio samples in Buffers.
 Currently I have a CCS (version 4.1.3.00038 ) project which runs well with FreeRTOS OS.
 I would like to provide you with this project as a baseline.
The delivery should include:
Add to the project given by me activation of Audio in/out (Mic in /Speakers Out ) peripheral (McASP) at rate of 44100Hz
along with usage of DMA , so that :
For Mic in: whenever the DMA finishes writing a buffer, an interrupt shall be triggered. After interrupt occurred it should be possible to retrieve the samples from the written buffer, and auto-retrigger of the next DMA buffer for receiving next samples. In order to avoid miss of samples due to the time of interrupt handling, 3 RX sample buffers shall be used so that DMA is first-time fed with 2 buffers (the 2nd one pending in DMA for the 1st to finish), so that at any point in time there will never be shortage in buffers to be used to receive samples.(so that when 1st finishes the 2nd is directly used by DMA CONTINUE and in the interrupt the 3rd is configured to be next ).THE BUFFERS ARE USED IN A CYCLIC WAY.
 An API shall be provided to START the “receive” never ending process.
 An API shall be provided to END the “receive” never ending process.
 An api shall be provided so the software handling the buffer read will “know” (at least by polling mechanism) when/which buffer was last received or if none was received
For Speakers out: whenever the DMA finishes reading a buffer, an interrupt shall be triggered. After interrupt occurred it should be possible to retrieve which buffer was just played so it can be refilled later on by other software and then retriggered into the DMA. In order to avoid miss of samples due to the time of interrupt handling, 2 TX sample buffers shall be used so that DMA is first-time fed with 2 buffers (the 2nd one pending in DMA for the 1st to finish), so that at any point in time there will never be shortage in buffers to be played.(so that when 1st buffer finishes being played the 2nd is directly played by DMA CONTINUE after ,and before the 2nd buffer is finished playing the software responsible for filling the buffer will already trigger the 1st buffer refilled with new samples - It is assumed that the software filling a buffer is much quicker than the time it takes to play out a buffer)
 An API shall be provided to START the “transmit” never ending process.
 An API shall be provided to END the “transmit” never ending process.
 An api shall be provided so the software handling the buffer filling will “know” when/which buffer was last transmitted (at least by polling mechanism) or if none was transmitted.
 Another api shall be provided whose input is a buffer index and it retriggers the DMA to play it after the currently playing buffer –( used by the software responsible for filling the buffers).