Something doesn't make sense. Say we take a case stated not to work, ie
16 kHz with CPU at 96 MHz. If
we assume stereo input and output running at simultaneously we have
16000 samples/sec x 4 audio channel x 1 EDMA transfer/audio channel =
64,000 EDMA transfer/second
Give a clock rate of 96 MHz that is
96,000,000 / 64,000 = 1,500 CPU cycles per EDMA transfer.
In my opinion there is something else going on.
- Andrew
Kevin Hilman wrote:
"Chaithrika U S" <[email protected]> writes:
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?
An alternative to relying on the user to change the CPUfreq policy is
to have the audio driver itself do that. Based on the sample rate and
clock frequency, the audio driver should be able to determine that the
EDMA rate will not be fast enough and set a CPUfreq policy so that
lower frequencies are not attempted. When the audio driver is done,
it can set the policy back.
Kevin
_______________________________________________
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
