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

[Mike Frysinger]

On Thu, Aug 26, 2010 at 14:06, Adam Rosenberg wrote:
> Thank you for the reply.  I emailed Barry Song on July 30th to request some
> help moving to the new ASoC standards but received no response.

developers shouldnt be e-mailed directly ... it isnt uncommon for them
to simply be punted.  this is why we have mailing lists and forums.

> I began writing this driver on the Blackfin uClinux 2009 release and based
> it on the AD1836 and AD1938 drivers.  I am now using the Blackfin SVN trunk
> and have found that the driver model was changed to ASoC.  It is not
> apparent how I would create a driver that supports two chips off of the same
> SPORT using the ASoC framework.
>
> The best I could do was use the same SPORT driver that the ASoC code uses
> (bf5xx-sport.c) so that I was at least up-to-date in that area.  I had to
> modify that driver so that it would support the secondary data lines of the
> SPORT.  I found that the driver did not function well in 2D DMA mode so I
> have to keep my period size below 64kb.  There is also a problem with
> starting Rx and Tx that causes the DMA data to be placed into the SPORT
> multichannel window incorrectly.  I added a function to the SPORT driver
> yesterday that can work around this problem by starting both Rx and Tx as
> normal then stopping the SPORT and restarting it like this:
>
> int sport_start_both(struct sport_device *sport)
> {
>     sport_tx_start(sport);
>     msleep(1);  // is this needed?
>     sport_rx_start(sport);
>     msleep(1);  // is this needed?
>     sport_stop(sport);
>     msleep(1);  // is this needed?
>     sport_start(sport);
>     return 0;
> }
> EXPORT_SYMBOL(sport_start_both);
>
> This ensures that the data from the DMA buffer is properly loaded into the
> SPORT multichannel window for both the Rx and Tx data lines.  If it is not
> done this way it seems that one of them is always being filled incorrectly.
> This may have sometime to do with the fact that I have to enable the
> secondary data lines but there is no clear explanation for why that would
> have an effect.
>
> 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.
>
> 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?
> 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?
> 3.  Can you suggest a good way to debug underrun/overrun problems?

i dont really know ASoC/SPORTs, so we'd have to get someone to look into it
-mike