On 07/02/2013 02:13 PM, Mark Brown wrote:
On Tue, Jul 02, 2013 at 07:50:16AM +0200, Mike Looijmans wrote:
On 07/02/2013 05:33 AM, Joel Fernandes wrote:
But even with much lower loads, I got underruns when recording to SD card that I couldn't really explain. I noticed that the SD transfers took up a lot of DMA params (about 40), so maybe that was just causing too much work for the IRQ or DMA handler routines.
SD cards are generally just slow, it's possible it's just not able to keep up with the data you're throwing at it. Things like batching the writes up into large chunks can help here but you may just be hitting a genuine limit if you need to record for too long and don't have enough fast storage (like RAM) to buffer.
What i meant by "couldn't really explain" is that I monitored CPU, memory and IO, and could clearly conclude that the card (or network, or even /dev/null on occasion) wasn't the bottleneck in itself. It's not so much the medium, but more the load it causes on the system that triggered the overruns.
This meant I had to use a DMA PARAM slot for every "period". The OMAP L138 has 128 of those slots, so it's no problem to use a bunch of them. Because the chain is cyclic, there is no need to update any DMA parameter while running. All that ALSA needs to do is empty the buffer before the cycle completes and the current position gets overwritten.
This sort of cyclic thing tends to be best, ideally you don't need interrupts at all (other than a timer).
Indeed. In this case, the DMA completion IRQ is still useful because the DMA controller issues it after the "period" data has been transferred completely. Just monitoring the DMA registers will tell which data is currently being transferred, but you can't be sure that it has actually been committed. So if the DMA pointer is now at 0x0100, you cannot be sure whether the data at 0x0100 is already valid, or even the data at 0x0098, because that might still be in the controller's queue. The pointer increments when the request is sent to the queue, but there's no guarantee as to when the queue will actually be executed, because other transactions may have higher priority.
Mike.