On Tue, Aug 24, 2010 at 03:47:13PM -0400, Adam Rosenberg wrote:
I am trying to write a driver for the Blackfin BF537 processor on a custom board that has two CS42448 CODECs connected to SPORT0. I am using TDM and
CCing in the Blackfin guys - this looks like a CPU specific issue. However, see below...
there are 8 channels per frame on each data line (primary and secondary). My DMA buffer must interleave the data for the two data lines (for a total of 16 channels of data per frame). I have completed all of this and the driver will sometimes work properly but I am having underrun problems. I would like to use snd_async_add_pcm_handler as it is used in the /test/pcm.c example but it seems as though an underrun occurs at regular intervals causing the PCM prepare function to be called again (this results in a tone that sounds good but only for a short time before it stops and then starts again).
There is plenty of time for the data to be transferred. I feel as though the driver is not calling snd_pcm_period_elapsed fast enough. At the moment, I call snd_pcm_period_elapsed from within a callback function that occurs every time a DMA period elapse occurs. I have been working on this for quite a while now. Is there someone who can look at the driver code for me or provide detailed information on when ALSA expects to have snd_pcm_period_elapsed get called to avoid an underrun?
The other thing that is strange is that I have to explicitly set the period size for aplay to work. For example: aplay --period-size=1024 test.wav which gives me a period time of 21333 but when I use this period time with the /test/pcm.c sample that is provided the tone still does not sound right (although it does seem to improve)
If you're needing to set the period size explicitly this probably indicates a problem with the way the constraints are being exposed to applicatiohns - normally the constraints would force an appropriate configuration to be selected.
I am about ready to bypass ALSA entirely but I hate the idea of breaking from standards (not to mention having to rewrite an entire audio interface). Any help would be greatly appreciated!
You can check out the driver here: http://www.alcorn.com/ftp/swap/ami_cs42448.zip
Please post code to the list if you want people to review it. Looking at the code there it looks like you've implemented your own custom driver entirely outside the standard ASoC framework and Blackfin drivers. It will be much easier to get community support with the standard kernel code, if you're not reusing any of the existing CPU support you're much more on your own.