Chaithrika,
Can you elaborate on your "EDMA runs at a lower speed" comment ? The
usual setup is to have McASP trigger EDMA transfer. An EDMA transfer
runs at CPU speed. It should be plenty fast enough at 96 MHz.
In the past I have seen issues where the CPU cache updating has priority
over the McASP transfer in the EDMA sub-system. That can cause McASP
underruns. I would first check that the EDMA is configured so that the
McASP transfer has priority over everything else. I'm not an expert on
EDMA3, but I think that was one of the improvements they made over
regular EDMA.
Cheers,
Andrew
Chaithrika U S wrote:
Kevin,
With the cpufreq support on DA850/OMAP-L138 SoC we are observing
that audio does not function as expected at all sampling rates
for various operating points. At a CPU frequency of 96MHz, audio
works fine with a sampling frequency of 8kHz. For other sampling
rates, there are lot of underrun/overrun errors. This is because
of EDMA also runs at a lower speed and is not able to transfer
data at the desired rate.
To overcome the above, we can depend on the user to set the scaling
min frequency to be the same as scaling max frequency (in this case
300 MHz) before starting aplay/arecord or temporarily move to
performance governor so that the audio quality is not affected.
Do you think this is the right approach to this problem? Any other
solutions you suggest exploring?
Regards,
Chaithrika
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
