On Fri, 17 Dec 2010, Manu Abraham wrote:
On Fri, Dec 17, 2010 at 10:28 AM, Manu Abraham abraham.manu@gmail.com wrote:
Hi,
By now I am a bit confused.
I am seeing a certain pattern in which the callbacks are invoked:
- hw_params()
- prepare()
- trigger(); // Start DMA
- pointer();
--> gets data after interrupt is handled
- trigger(); // Stop DMA
- prepare();
- trigger(); // Start DMA
- pointer();
--> gets data after interrupt is handled
.. ..
and so on.
Is this the right behaviour that's expected from a function ALSA capture driver ? I am trying to understand why there is Start DMA, Stop DMA, Start DMA, Stop DMA in a cyclic fashion for each of the interrupts in my setup.
To test my theory that a STOP cmd after an interrupt was giving me the same buffer location, I did commented out the STOP cmd, as well, allowing the START cmd to run only if the streaming engine has not START 'ed.
This allows the interrupt handler to fire correctly with the correct buffer indices, as seen in the following logs.
The problem is that,
- I don't understand why the application issues a CMD to STOP/START,
after each interrupt. 2. The STOP/START cmds reinitializes the Streaming engine to start with buffer index:0, therefore always buffer position is at the very beginning of the buffer.
I believe that your pointer callback is buggy so the midlevel code things that you had and overrun.
http://www.alsa-project.org/main/index.php/XRUN_Debug
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.