how does alsa keep passing data into driver?

how does alsa keep passing data into driver?

[Tehn Yit Chin]

[-- Attachment #1: Type: text/plain, Size: 526 bytes --]

Hi,

I am trying to understand how the ALSA pass PCM data to the driver. I have
understand that when the driver starts up, a start trigger event is created
and some PCM data is passed in. After that, how does the subsequent PCM data
get pass into the driver?

I also realise that a pointer event is generated, but from the docs, the
pointer event is for figuring out the current position.

I am currently working with the S3c2410 cpu and the code s3c2410-iis.c.

Any pointers would be appreciated.
Tehn Yit Chin

[-- Attachment #2: Type: text/html, Size: 568 bytes --]

RE: how does alsa keep passing data into driver?

[Giuliano Pochini]

On 14-Oct-2005 Tehn Yit Chin wrote:

> I am trying to understand how the ALSA pass PCM data to the driver. I have
> understand that when the driver starts up, a start trigger event is created
> and some PCM data is passed in. After that, how does the subsequent PCM data
> get pass into the driver?

The ALSA middle layer passes PCM data to the driver only if the driver
attaches a function to the .copy() callback. Otherwise (and this is the
most common case) the ALSA ml copies data to/from the buffer on its own.


> I also realise that a pointer event is generated, but from the docs, the
> pointer event is for figuring out the current position.

Yep. ALSA needs to know what part of the buffer has been consumed so it
can copy new data to/from that part.


--
Giuliano.


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: how does alsa keep passing data into driver?

[Tehn Yit Chin]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

On 10/14/05, Giuliano Pochini <pochini@shiny.it> wrote:
>
>
> On 14-Oct-2005 Tehn Yit Chin wrote:
>
> > I am trying to understand how the ALSA pass PCM data to the driver. I
> have
> > understand that when the driver starts up, a start trigger event is
> created
> > and some PCM data is passed in. After that, how does the subsequent PCM
> data
> > get pass into the driver?
>
> The ALSA middle layer passes PCM data to the driver only if the driver
> attaches a function to the .copy() callback. Otherwise (and this is the
> most common case) the ALSA ml copies data to/from the buffer on its own.


So when would it appropriate to attached a function to the .copy callback?
Are you able to give me a clue which function actual performs the copying in
the ALSA middle layer?

Thanks for you reponse thus far.

[-- Attachment #2: Type: text/html, Size: 1154 bytes --]

Re: how does alsa keep passing data into driver?

[James Courtier-Dutton]

Tehn Yit Chin wrote:
> On 10/14/05, Giuliano Pochini <pochini@shiny.it> wrote:
> 
>>
>>On 14-Oct-2005 Tehn Yit Chin wrote:
>>
>>
>>>I am trying to understand how the ALSA pass PCM data to the driver. I
>>
>>have
>>
>>>understand that when the driver starts up, a start trigger event is
>>
>>created
>>
>>>and some PCM data is passed in. After that, how does the subsequent PCM
>>
>>data
>>
>>>get pass into the driver?
>>
>>The ALSA middle layer passes PCM data to the driver only if the driver
>>attaches a function to the .copy() callback. Otherwise (and this is the
>>most common case) the ALSA ml copies data to/from the buffer on its own.
> 
> 
> 
> So when would it appropriate to attached a function to the .copy callback?
> Are you able to give me a clue which function actual performs the copying in
> the ALSA middle layer?
> 
> Thanks for you reponse thus far.
> 

Most sound cards use DMA to transfer sound samples from memory to the 
sound card hardware. The trigger(start) function initiates these DMA 
transfers, and the sound card controls the DMA. The sound card will just 
continue to repeat DMA transfers until told to trigger(stop). Each time 
a DMA transaction completes, an interrupt is generated. Each DMA 
transaction normally transfers one period of samples at a time from the 
ring buffer, so the interrupt routine calls period_elapsed to tell the 
rest of alsa that some samples have been transfered to the sound card. 
Inside period_elapsed, the hardware pointer in updated, so that alsa 
knows the current state of the sample ring buffer. If the sound 
application uses a callback method, this callback is then scheduled, and 
the sound application can then transfer another period of samples to the 
ring buffer.

If your sound card cannot do DMA transfers, you still need to ensure 
that the sound card can still generate interrupts. So the period_elapsed 
function is still called for each samples period. You then need to 
ensure that during the period_elapsed call, new samples are written to 
the sound card hardware. To do this, you implement the .copy function, 
and period_elapsed will call that to transfer the samples to the sound 
card on each interrupt.

If your sound card cannot generate interrupts for each samples period, 
you basically cannot use it with Linux.

I hope this helps

James


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: how does alsa keep passing data into driver?

[Eliot Blennerhassett]

On Mon, 17 Oct 2005 04:26, James Courtier-Dutton wrote:
> If your sound card cannot generate interrupts for each samples period,
> you basically cannot use it with Linux.

Not so.
You can use a timer to poll the card instead of an interrupt. 
See the "dummy" driver

--
Eliot


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl