Low Latency, Low overhead Audio IO Shell/Framework for 6748?

Shawn Steenhagen

Other Parts Discussed in Thread: OMAPL138

PSP: 01_30_01 BIOS: 5_31_10_06 EDMA3_lld_01_11_03_01 CCS: 4.2.5

Logic PD L138 experimeters kit.

I am trying to use the 6748 portion of a L138 for a project. The design objective is to run the Audio Codecs at 96000, downsample to 8KHz, and run a control algorithm at the 8KHz sample rate.

I have used the audio example from the PSP (C:\Program Files\Texas Instruments\pspdrivers_01_30_01\packages\ti\pspiom\examples\evm6748\audio) as a starting point for this project, changing the sample rate to 96000 and the framesize to 12, to achieve the 8Khz sample rate (96000/12 = 8Khz).

I've added several sts objects within the project and have determined that the device driver/bios overhead is about 30,000 dsp cycles. In other words, from the time the 12 samples are ready to the time the for loop within Audio_Echo_Task( ) is called again, about 30,000 cycles have been exhausted. With a 300Mhz c6748, and a frame rate of 8Khz, there are 300Mhz/8Khz = 37,500 dsp cycles available to process the i/o. With the overhead using up 30,000 of those cycles, (80% of CPU), that does not leave enough CPU left over for the control algorithm.

(Note: The above metric was taken using the debug versions of the psp libraries)

Does TI (or anyone for that matter) have any other audio echo shell examples that don't use the PSP that perhaps are a leaner and more effecient? I'm looking for a simple example that can take a frame size of 12, use the DMA with a simple ping pong buffer and maybe just post a SWI when the 12 samples are ready.

Any Suggestions?

-S

over 14 years ago

0 Fawad Nackvi62335 over 14 years ago

Expert 1080 points

This is for the C6747 but it should work on the C6748.

http://processors.wiki.ti.com/index.php/Tuning_Audio_Latency_on_C6747

Fawad

0 Sandeep Krishnaswamy over 14 years ago

TI__Expert 7290 points

Shawn,

As part of the release testing we have done profiling for McASP on DSP of OMAPL138. Profiling results are available in the section 3.8 of "pspdrivers_01_30_01\docs\OMAPL138\OMAPL138_BIOSPSP_Datasheet.pdf". The document list out CPU load for different sample size.

Thanks and Regards,

Sandeep k

0 Shawn Steenhagen over 14 years ago in reply to Sandeep Krishnaswamy

Expert 1535 points

Yes, the data sheets confirm that the PSP/EDMA/BIOS implementation takes on the order of 45,000 dsp cycles to run a simple echo program (Assuming a 300Mhz clock, looking at the frame size = 24 data point, with cpu loading listed as 30%, Frame Rate = 48Khz/24 = 2Khz. Available cycles = 300Mhz/2Khz = 150K. 30% of 150K = 45,000 dsp cycles).

I'm trying to run codecs at fs=96000, with a frame size of 12, which will exhaust all resources. This is why I am looking for a different solution. The reply above references an example on the 6747 that does not use the PSP/EMDA:

http://processors.wiki.ti.com/index.php/Tuning_Audio_Latency_on_C6747

Which references this product:

http://software-dl.ti.com/dsps/dsps_public_sw/c6000/web/c6747_audio_edma_app/latest/index_FDS.html

Do you have this product ready to go for the 6748?

-S

0 Sandeep Krishnaswamy over 14 years ago in reply to Shawn Steenhagen

TI__Expert 7290 points

Shawn,

Shawn S. said:

Yes, the data sheets confirm that the PSP/EDMA/BIOS implementation takes on the order of 45,000 dsp cycles to run a simple echo program (Assuming a 300Mhz clock, looking at the frame size = 24 data point, with cpu loading listed as 30%, Frame Rate = 48Khz/24 = 2Khz. Available cycles = 300Mhz/2Khz = 150K. 30% of 150K = 45,000 dsp cycles).

If you look at the driver implementation, the CPU will be active only when the packet is queued & programmed to the EDMA and then during the EDMA completion interrupt service. So the CPU will be idle during the actual data transfer between the McASP FIFO and the DDR.

So, as per the data sheet, for 48KHz sampling rate and for number of sample 24 (i.e so many words are requested from the application), the 30% of the 300MHz will be consumed.

Shawn S. said:

http://processors.wiki.ti.com/index.php/Tuning_Audio_Latency_on_C6747

Which references this product:

http://software-dl.ti.com/dsps/dsps_public_sw/c6000/web/c6747_audio_edma_app/latest/index_FDS.html

Do you have this product ready to go for the 6748?

Let me check on this..

Regards,

Sandeep K

0 Sandeep Krishnaswamy over 14 years ago in reply to Shawn Steenhagen

TI__Expert 7290 points

Shawn S. said:

Yes, the data sheets confirm that the PSP/EDMA/BIOS implementation takes on the order of 45,000 dsp cycles to run a simple echo program (Assuming a 300Mhz clock, looking at the frame size = 24 data point, with cpu loading listed as 30%, Frame Rate = 48Khz/24 = 2Khz. Available cycles = 300Mhz/2Khz = 150K. 30% of 150K = 45,000 dsp cycles).

I'm trying to run codecs at fs=96000, with a frame size of 12, which will exhaust all resources. This is why I am looking for a different solution. The reply above references an example on the 6747 that does not use the PSP/EMDA:

http://processors.wiki.ti.com/index.php/Tuning_Audio_Latency_on_C6747

Which references this product:

http://software-dl.ti.com/dsps/dsps_public_sw/c6000/web/c6747_audio_edma_app/latest/index_FDS.html

Do you have this product ready to go for the 6748?

-S

There is no ready product for C6748, you have to port it from C6747 to C6748. You can refer the audio/codec/mcasp driver of the 1.30.01 to know the difference between C6748 and the C6747 OR please refer the TRM.

Regards,

Sandeep K

Processors

Processors forum

Low Latency, Low overhead Audio IO Shell/Framework for 6748?