[alsa-devel] What recommended performance for ALSA(ASoC)?
Hello, I tred developing new ALSA(ASoC) driver for our company's embedded processor. Our processor supported I2S and DMA. So, my ALSA drvier implementation using DMA. I was tested my ALSA driver. When I play wav file(sample rate 44100) using aplay( aplay -M -D hw:0,0 test.wav), sometimes occured breaks. Also, play mp3 file(sample rate 44100Hz) using madplay and mpg123, sometimes occured noises. So, I was tested wav file and mp3 file that down sampling 44100 -> 22050. They was not occurring break and decreasing noises. I tried improving my ALSA driver, optimize souce code and change variety buffer size and period size. But It doesn't improve much. In my guess, my target system is not enough performance because ALSA is heavy. Target system' processor(ARM9) clock is 200MHz and BogoMIPS is 99.6(cat /proc/cpuinfo). Linux kernel version is 2.6.24.1.
What recommended performance for ALSA(ASoC)? If my target system is enough performance, shall I do that solve problem?
Thanks.
On Fri, 7 Mar 2008, Jinyoung Park wrote:
Hello, I tred developing new ALSA(ASoC) driver for our company's embedded processor. Our processor supported I2S and DMA. So, my ALSA drvier implementation using DMA. I was tested my ALSA driver. When I play wav file(sample rate 44100) using aplay( aplay -M -D hw:0,0 test.wav), sometimes occured breaks. Also, play mp3 file(sample rate 44100Hz) using madplay and mpg123, sometimes occured noises. So, I was tested wav file and mp3 file that down sampling 44100 -> 22050. They was not occurring break and decreasing noises. I tried improving my ALSA driver, optimize souce code and change variety buffer size and period size. But It doesn't improve much. In my guess, my target system is not enough performance because ALSA is heavy. Target system' processor(ARM9) clock is 200MHz and BogoMIPS is 99.6(cat /proc/cpuinfo). Linux kernel version is 2.6.24.1.
What recommended performance for ALSA(ASoC)? If my target system is enough performance, shall I do that solve problem?
It looks like that your driver has trouble with highter rates. Also, try to measure where the problem occurs. Maybe your system is not able to deliver data from source in time to sound DMA buffer for continuous playback. Note that whole system must be tuned not only ALSA driver to get satisfiable results. DMA+mmap transfers are pretty lightweight in ALSA, but if disc read operation eats too much CPU time, you cannot expect good results.
Regarding noises - I would check if DMA ring buffer position reported from driver is correct in application. It looks like a handshake or maybe cache problem.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On Fri, Mar 07, 2008 at 08:49:09AM +0100, Jaroslav Kysela wrote:
On Fri, 7 Mar 2008, Jinyoung Park wrote:
Target system' processor(ARM9) clock is 200MHz and BogoMIPS is 99.6(cat /proc/cpuinfo). Linux kernel version is 2.6.24.1.
What recommended performance for ALSA(ASoC)? If my target system is enough performance, shall I do that solve problem?
That should be more than enough in terms of CPU performance - it's fairly typical for an ASoC-based system.
It looks like that your driver has trouble with highter rates. Also, try to measure where the problem occurs. Maybe your system is not able to deliver data from source in time to sound DMA buffer for continuous playback. Note that whole system must be tuned not only ALSA driver to get satisfiable results. DMA+mmap transfers are pretty lightweight in ALSA, but if disc read operation eats too much CPU time, you cannot expect good results.
If the CPU is busy it's also worth ensuring that the playback format you are using is directly supported by the hardware to avoid the CPU having to do any additional transcoding.
Regarding noises - I would check if DMA ring buffer position reported from driver is correct in application. It looks like a handshake or maybe cache problem.
Also check that the clocking of the audio subsystem isn't going to be introducing any glitches. You usually want to ensure that the audio parts of the system are part of a single clocking domain.
participants (3)
-
Jaroslav Kysela -
Jinyoung Park -
Mark Brown