My English is not very good,which may confuse you sometimes,so thank you for going into the trouble to help me.
I am working on a driver for an audio codec chip called cs4341 on dm6467,using alsa.The kernel version i use is 2.6.18,and the alsa 1.0.11.
When i want to play a file of the type wav with the alsa's player aplay,it always results with the following errors:
root@192.201.0.10:~# aplay sound/WindowsXP.wav
Playing WAVE 'sound/WindowsXP.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
underrun!!! (at least 450.416 ms long)
underrun!!! (at least 69.908 ms long)
underrun!!! (at least 61.305 ms long)
underrun!!! (at least 80.735 ms long)
underrun!!! (at least 59.629 ms long)
underrun!!! (at least 61.753 ms long)
underrun!!! (at least 56.203 ms long)
underrun!!! (at least 54.311 ms long)
Not only the music played is off and on because of "underrun",but also i can hear that some audio date is lost once in a while.
Some of the information on internet mentioned that it may be result from the problem of pcm_point which indicates how many frames have been sent by dma. I analysed it, and found that although i specified the period size of dma to 1500 frames, in fact,the frames it transferred each cycle is in an irregular number such as 1023 , 798 ,1455. I do not know whether a situation like this is normal or not.
I thought that at first,in the transmission process, there should be a coordination between dma and user process.the dma controller get audio data from dma buffer and sent them to the serial port of mcasp., and the user application write data to the dma buffer when there is enough space.
But I found that, in the case of non-asynchronous notification, user application did't trigger the mcasp and dma,before it feed the dma buffer to full
, then, in the handler of each period dma interrupt,the driver is not able to wake up the user process,and the transmission will not stop untill the whole buffer is sent. At the same function,the pcm state is set to underrun,which confused me very much.I mean,the "underrun"is not generated by hardware in mcasp but set by the code in the driver layer.
As for asynchronous notification mode, the signal sent to the user layer by the driver can not be responsed by the callback function in the user application.
I am sorry but i feel really hard to express my problem more clearly to you in English,and i will try my best if there is any answer.