[alsa-devel] callbacks order while capturing from Line-IN

Jaroslav Kysela perex at perex.cz
Fri Dec 17 07:21:05 CET 2010


On Fri, 17 Dec 2010, Manu Abraham wrote:

> On Fri, Dec 17, 2010 at 10:28 AM, Manu Abraham <abraham.manu at 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.
>
> 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 at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.


More information about the Alsa-devel mailing list