> -----Original Message----- > From: [email protected] > [mailto:[email protected] > ] On Behalf Of Kevin Hilman > Sent: Wednesday, January 06, 2010 5:09 AM > To: Subrahmanya, Chaithrika > Cc: [email protected] > Subject: Re: Audio quality with CPU frequency scaling > > "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, Wouldn't this mean that driver is directly influencing the policy? Best regards, Sanjeev > > 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
