On Fri, 17 Dec 2010, Manu Abraham wrote:
On Fri, Dec 17, 2010 at 10:28 AM, Manu Abraham <abraham.manu@xxxxxxxxx> 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.
http://pastebin.ca/2021840
The problem is that,
1. 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@xxxxxxxx>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
