[alsa-devel] Problem with underrun on new CS42448 x2 driver

[Adam Rosenberg]

> 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