> 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: >> 1. 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" > >> 2. 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? > >> 3. 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
