[alsa-devel] Problem with underrun on new CS42448 x2 driver
adam at alcorn.com
Fri Aug 27 22:11:48 CEST 2010
> 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
>> 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
> 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
Thanks and have a great weekend,
More information about the Alsa-devel