Re: FW: DMA producer/consumer

[Takashi Iwai <tiwai@suse.de>]

At Thu, 11 Mar 2004 09:30:31 +0530,
Gupta, Kshitij wrote:
> 
> Any comments on this would be really helpful...
> 
> -----Original Message-----
> From: alsa-devel-admin@lists.sourceforge.net
> [mailto:alsa-devel-admin@lists.sourceforge.net]On Behalf Of Gupta,
> Kshitij
> Sent: Wednesday, March 10, 2004 5:06 PM
> To: alsa-devel@lists.sourceforge.net
> Subject: [Alsa-devel] DMA producer/consumer
> 
> 
> hi,
> 	
> 
> A typical core pcm playback flow (simplified for representation) 
> 
> 
> static void arch_pcm_start_dma(struct arch_pcm_runtime *s)
> {
> 	...	
> 	
> 	ret = __arch_start_dma(s->dma_ch, pos, s->dma_size);
> 	...
> 	ssr->dma_pos = pos;
> }
> 
> 
> static void arch_pcm_dma_callback(void *data)
> {
> 	...
> 	
> 	if (s->stream)
> 		snd_pcm_period_elapsed(s->stream);
> 
> 	spin_lock(&s->lock);
> 	if (s->state & ST_RUNNING)
> 		arch_pcm_start_dma(s);
> 	spin_unlock(&s->lock);
> 	
> 	...
> }
> 
> static int chip_pcm_trigger(snd_pcm_substream_t *substream, int cmd)
> {
> 	...
> 
> 	switch (cmd) {
> 	case SNDRV_PCM_TRIGGER_START:
> 		arch_clear_dma(s->dma_ch);
> 		arch_pcm_start_dma(s->dma_ch);
> 		...		
> 		break;
> 
> 	...	
> }
> 
> 
> Now in this flow chip_pcm_trigger calls the arch_pcm_start_dma, which then
> starts a dma transfer.  Callback is called when the dma transfer ends, which
> then notifies the ALSA middle layer about the end of one period and then
> starts another dma transfer.  
> 
> The question I want to ask is about the continuity of data transferred to
> the actual codec.  In the above flow, next dma transfer is started only when
> the previous one ends.  So this mechanism will give us small jitters in the
> audio playback.  

unfortunately, the current implementation of ALSA PCM middle layer
isn't well suited for this kind of hardwares.  it'll be a bit more
complicated than you think.

basically, the dma queueing can be done in the ack callback.
this is used for the hardwares with indirect buffer transfer, such as
emu10k1's fx pcm or cs46xx's pcms.  check pci/emu10k1/emufx.c or
pci/cs46xx/cs46xx_lib.c.

with this mechanism, you'll need to book-keep appl_ptr by yourself,
and check the difference between the actual runtime->control->appl_ptr
and the local last_ptr values.  if the enough data is available, feed
to dma queue.  this callback should be called appropriately in trigger
and pointer callbacks, so that the appl_ptr is updated as best.

maybe we should clean up the implementation later for these
hardwares...


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click