Please don't top post, and remember to include context in your reply so people can understand the context of your message0. This is standard for Linux kernel mailing lists.
Thanks, no more top posts for me...
I have not entered any constraints into the driver because there really should be no need. The driver just copies whatever PCM data that is provided directly to the DMA buffer. It seems that the problem occurs because the location to copy to is based on the pos suggested by the callback function. I am still finding it difficult to tell how ALSA decides there is an underrun or overrun. I am definitely trying to read or write the pcm data fast enough but it seems as though I get these errors anyway.
I've no idea what "the callback function" is?
The callback function is the PCM copy function that I define in struct snd_pcm_ops
Questions:
- How do I implement an ASoC-style driver that supports multiple chips
when they are connected to the same SPORT but use different SPI chip selects?
Look at current ASoC in -next, I've never tried this multi drop DAI setup directly myself but it does support multiple CODECs in the system.
I could not find anything in the linux-2.6.x/sound/soc/ directory called "next" and cannot find any documentation in linux-2.6.x/Documentation/sound/alsa/soc about "multi drop"
- How do I define the proper buffer/period size constraints or should I
ignore the suggested position during copy operations and just keep track of the position within the DMA buffer myself?
Your constraints will flow from the requirements of the hardware plus any additional requirements that the driver you've written imposes. For example, if you always need a period of data ready to start DMA on which the application can't touch for coherency reasons then you need to make sure that there's at least three periods (running, about to run and updatable), or if your hardware DMAs in blocks you need a minimum period size for that.
This information was a little cryptic at first. It turns out it was the diamond in the rough though. I set periods_min in struct snd_pcm_hardware to 3 and it solved quite a few underrun problems.
Question: Is there a way I can force ALSA to always use a period size that is a multiple of 16?
- Can you suggest a good way to debug underrun/overrun problems?
There's a few settings for XRUN detection diagnostics in the ALSA core code which can be useful - see pcm_lib.c and the SND_PCM_XRUN_DEBUG config option.
Thank you for this tip. It turns out you need to enable SND_VERBOSE_PROCFS to see this option in the kernel configuration. I am hoping this additional debug information may help me to figure out why plughw has never been able to properly convert the sample rate for me.
Thanks and have a great weekend, Adam