FW: DMA producer/consumer

FW: DMA producer/consumer

[Gupta, Kshitij]

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.  

Hardware provides us the mechanism of queueing another dma transfer even
before the first one ends, so that the queued dma transfer starts as soon as
the first one ends (and this is done at the hardware level).  But the
question is that where should we queue another dma transfer.  Or do you guys
suggest that there is no need of doing a queued dma transfer.

Also another question is that how do we make sure that data we are dma'ing
is filled up by the ALSA middle layer (shall we use appl_ptr to check that).

warm regards
-kshitij


-------------------------------------------------------
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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel


-------------------------------------------------------
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

Re: FW: DMA producer/consumer

[Takashi Iwai]

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

Re: FW: DMA producer/consumer

[Jaroslav Kysela]

On Thu, 11 Mar 2004, Takashi Iwai wrote:

> 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.

I don't think that's this case. I'm not sure, if the basic midlevel 
mechanism is understood: The midle level code expects that driver 
start/stop the stream in the trigger callback, so if you can queue
more 'periods' into the DMA engine, do it and abort/pause the transfer
only the trigger callback request. You don't need to check appl/hw_ptr
in the lowlevel code.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
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

Re: FW: DMA producer/consumer

[Takashi Iwai]

At Thu, 11 Mar 2004 18:43:39 +0100 (CET),
Jaroslav wrote:
> 
> On Thu, 11 Mar 2004, Takashi Iwai wrote:
> 
> > 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.
> 
> I don't think that's this case. I'm not sure, if the basic midlevel 
> mechanism is understood: The midle level code expects that driver 
> start/stop the stream in the trigger callback, so if you can queue
> more 'periods' into the DMA engine, do it and abort/pause the transfer
> only the trigger callback request. You don't need to check appl/hw_ptr
> in the lowlevel code.

hmm, if i understand correctly, this DMA engine needs the update of
DMA queue.  i.e. the driver needs to feed chunks manually in prior
to the DMA start, and continues feeding the available chunks after
that as long as the stream is running.  this is somewhat analogous
with the case with the external hardware buffer.

correct me if i'm wrong.


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

Re: FW: DMA producer/consumer

[Jaroslav Kysela]

On Thu, 11 Mar 2004, Takashi Iwai wrote:

> At Thu, 11 Mar 2004 18:43:39 +0100 (CET),
> Jaroslav wrote:
> > 
> > On Thu, 11 Mar 2004, Takashi Iwai wrote:
> > 
> > > 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.
> > 
> > I don't think that's this case. I'm not sure, if the basic midlevel 
> > mechanism is understood: The midle level code expects that driver 
> > start/stop the stream in the trigger callback, so if you can queue
> > more 'periods' into the DMA engine, do it and abort/pause the transfer
> > only the trigger callback request. You don't need to check appl/hw_ptr
> > in the lowlevel code.
> 
> hmm, if i understand correctly, this DMA engine needs the update of
> DMA queue.  i.e. the driver needs to feed chunks manually in prior
> to the DMA start, and continues feeding the available chunks after
> that as long as the stream is running.  this is somewhat analogous
> with the case with the external hardware buffer.

It was case for sb8 driver, I think that all newer hardware which can do
DMA transfers is designed to enqueue more blocks to avoid fifo underruns 
at the block boundary. At least the SA11xx ARM platform has the DMA engine 
for two blocks (one can be prepared during transfer of the opposite).

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
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

RE: FW: DMA producer/consumer

[Gupta, Kshitij]

hi,

	Even thought the SA11xx ARM platform DMA engine has a queueing
mechanism (as you mentioned), it is not being utilized.  Since we are
queueing(or starting) the next dma transfer in the interrupt context, and we
recieve this interrupt only when the previous dma transfer ends.  Queueing
makes sense only when a dma transfer is active and we queue another dma
transfer (to avoid a delay between starting another transfer).  
So for now I think we might have to use the mechanisms suggested by Takashi
to queue extra periods to the dma engine.

regards
-kshitij

-----Original Message-----
From: Jaroslav Kysela [mailto:perex@suse.cz]
Sent: Thursday, March 11, 2004 11:30 PM
To: Takashi Iwai
Cc: Gupta, Kshitij; alsa-devel@lists.sourceforge.net
Subject: Re: FW: [Alsa-devel] DMA producer/consumer


On Thu, 11 Mar 2004, Takashi Iwai wrote:

> At Thu, 11 Mar 2004 18:43:39 +0100 (CET),
> Jaroslav wrote:
> > 
> > On Thu, 11 Mar 2004, Takashi Iwai wrote:
> > 
> > > 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.
> > 
> > I don't think that's this case. I'm not sure, if the basic midlevel 
> > mechanism is understood: The midle level code expects that driver 
> > start/stop the stream in the trigger callback, so if you can queue
> > more 'periods' into the DMA engine, do it and abort/pause the transfer
> > only the trigger callback request. You don't need to check appl/hw_ptr
> > in the lowlevel code.
> 
> hmm, if i understand correctly, this DMA engine needs the update of
> DMA queue.  i.e. the driver needs to feed chunks manually in prior
> to the DMA start, and continues feeding the available chunks after
> that as long as the stream is running.  this is somewhat analogous
> with the case with the external hardware buffer.

It was case for sb8 driver, I think that all newer hardware which can do
DMA transfers is designed to enqueue more blocks to avoid fifo underruns 
at the block boundary. At least the SA11xx ARM platform has the DMA engine 
for two blocks (one can be prepared during transfer of the opposite).

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
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

RE: FW: DMA producer/consumer

[Jaroslav Kysela]

On Fri, 12 Mar 2004, Gupta, Kshitij wrote:

> hi,
> 
> 	Even thought the SA11xx ARM platform DMA engine has a queueing
> mechanism (as you mentioned), it is not being utilized.  Since we are
> queueing(or starting) the next dma transfer in the interrupt context, and we
> recieve this interrupt only when the previous dma transfer ends.  Queueing

It's bad usage. For SA11xx (see sa1100_start_dma function in 2.6 kernels),
you can queue one buffer while other is running. So, you need to queue two
blocks (periods) at the start of stream in trigger() and later - in the
interrupt contents - queue next period ahead.

I admit that the current SA11xx code in ALSA driver is for 2.4 kernels 
where the queuing mechanism was not very good.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
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

RE: FW: DMA producer/consumer

[Gupta, Kshitij]

hi Jaroslav,
	yeah I completely agree with you.  We can always queue upfront, and
then in interrupt context queue next period.  But the only issue I see is
that when we queue a next period, are we sure that the middle layer has
already filled up this next period fully.  Don't we have to check this
before queueing a next period.  
regards
-kshitij

-----Original Message-----
From: Jaroslav Kysela [mailto:perex@suse.cz]
Sent: Friday, March 12, 2004 3:03 PM
To: Gupta, Kshitij
Cc: Takashi Iwai; alsa-devel@lists.sourceforge.net
Subject: RE: FW: [Alsa-devel] DMA producer/consumer


On Fri, 12 Mar 2004, Gupta, Kshitij wrote:

> hi,
> 
> 	Even thought the SA11xx ARM platform DMA engine has a queueing
> mechanism (as you mentioned), it is not being utilized.  Since we are
> queueing(or starting) the next dma transfer in the interrupt context, and
we
> recieve this interrupt only when the previous dma transfer ends.  Queueing

It's bad usage. For SA11xx (see sa1100_start_dma function in 2.6 kernels),
you can queue one buffer while other is running. So, you need to queue two
blocks (periods) at the start of stream in trigger() and later - in the
interrupt contents - queue next period ahead.

I admit that the current SA11xx code in ALSA driver is for 2.4 kernels 
where the queuing mechanism was not very good.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
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

RE: FW: DMA producer/consumer

[Jaroslav Kysela]

On Fri, 12 Mar 2004, Gupta, Kshitij wrote:

> hi Jaroslav,
> 	yeah I completely agree with you.  We can always queue upfront, and
> then in interrupt context queue next period.  But the only issue I see is
> that when we queue a next period, are we sure that the middle layer has
> already filled up this next period fully.  Don't we have to check this
> before queueing a next period.  

Ok, but when are samples transferred to the codec (or better - taken from
the memory)? There is usually only small fifo (16-64 bytes or something
like this) on the bus which is continuously filled. The audio samples are
filled ahead from application, too. So the time frame where "broken"
samples can be transferred to end device is very small so you don't need
to check for this condition in the lowlevel driver. As far, as I know, all
audio hardware works in this way.

I assume that the DMA engine does DMA transfers for you and the DMA 
engine works with samples directly from the ALSA's ring buffer. If this 
assumption is not true (you have to prepare/copy samples to another 
location for the DMA engine), then it might be problem and you need to 
solve it in another way as Takashi suggested.


						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
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

RE: FW: DMA producer/consumer

[Gupta, Kshitij]

hi,

	No no I was asking about the transfer of data from Application to
the ring buffer (which is performed by ALSA middle layer),  let me reframe
the doubt I have.  
When we queue a next period to the DMA engine, we have no idea whether data
for the next period has been already filled up ( filled up means --> data
filled up by Alsa middle layer , which is sent by the application ).  So
before queueing a next period to the DMA engine we will have to check
whether the ring buffer has sufficient data or not (because DMA will
transfer even if it is empty).  And for that purpose we might need to use
appl_ptr , which you said is a bad idea.

regards
-kshitij

ps: the assumptions you said about small fifo and DMA engine are also true

-----Original Message-----
From: Jaroslav Kysela [mailto:perex@suse.cz]
Sent: Friday, March 12, 2004 3:19 PM
To: Gupta, Kshitij
Cc: Takashi Iwai; alsa-devel@lists.sourceforge.net
Subject: RE: FW: [Alsa-devel] DMA producer/consumer


On Fri, 12 Mar 2004, Gupta, Kshitij wrote:

> hi Jaroslav,
> 	yeah I completely agree with you.  We can always queue upfront, and
> then in interrupt context queue next period.  But the only issue I see is
> that when we queue a next period, are we sure that the middle layer has
> already filled up this next period fully.  Don't we have to check this
> before queueing a next period.  

Ok, but when are samples transferred to the codec (or better - taken from
the memory)? There is usually only small fifo (16-64 bytes or something
like this) on the bus which is continuously filled. The audio samples are
filled ahead from application, too. So the time frame where "broken"
samples can be transferred to end device is very small so you don't need
to check for this condition in the lowlevel driver. As far, as I know, all
audio hardware works in this way.

I assume that the DMA engine does DMA transfers for you and the DMA 
engine works with samples directly from the ALSA's ring buffer. If this 
assumption is not true (you have to prepare/copy samples to another 
location for the DMA engine), then it might be problem and you need to 
solve it in another way as Takashi suggested.


						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
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

RE: FW: DMA producer/consumer

[Jaroslav Kysela]

On Fri, 12 Mar 2004, Gupta, Kshitij wrote:

> hi,
> 
> 	No no I was asking about the transfer of data from Application to
> the ring buffer (which is performed by ALSA middle layer),  let me reframe
> the doubt I have.  
> When we queue a next period to the DMA engine, we have no idea whether data
> for the next period has been already filled up ( filled up means --> data
> filled up by Alsa middle layer , which is sent by the application ).  So
> before queueing a next period to the DMA engine we will have to check
> whether the ring buffer has sufficient data or not (because DMA will
> transfer even if it is empty).  And for that purpose we might need to use
> appl_ptr , which you said is a bad idea.
> 
> ps: the assumptions you said about small fifo and DMA engine are also true

Fine, I think that you didn't catch my point:

1) midlevel calls trigger(START)
   - the lowlevel driver enqueues two blocks (periods) to DMA engine here
2) dma engine starts to transfer first block (period)
3) dma engine finished to transfer first block (period) and triggered
   interrupt; dma engine start to transfer the second block automatically
   (because it was enqueued in trigger)
4) lowlevel driver calls snd_pcm_period_elapsed() in the interrupt handler
5) midlevel code decides in the snd_pcm_period_elapsed() if underrun 
   occured (no more data) and if this condition is true, trigger(STOP)
   callback is called and the lowlevel driver aborts the DMA operation
6) if midlevel code has enough data from application - no trigger callback
   is called
7) lowlevel driver should enqueue next DMA block (period) ahead - this 
   operation might be done in the start of interrupt handler before 
   snd_pcm_period_elapsed() is called

So, in this algorithm, there is only a very small time window between
the interrupt condition and aborting of the DMA transfer in the 
trigger(STOP) callback which is acceptable. Note that underruns or 
overruns (xruns in our terminology ;-)) are bad and should not happen
when the system has a good configuration. So a transfer of a few "wrong" 
samples is acceptable in this case.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
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

RE: FW: DMA producer/consumer

[Gupta, Kshitij]

hi,
	:) maps almost perfectly ...thanx a lot.  Only other doubt I had
was, why are we always getting underruns in case of ARM (as Russell also
pointed out that there are some cache coherency problems), but I am not able
to map cache coherency problems to the underruns we are getting.  We are
getting underruns consistently, even with very small period size (about 1k).

regards
-kshitij

-----Original Message-----
From: Jaroslav Kysela [mailto:perex@suse.cz]
Sent: Friday, March 12, 2004 3:45 PM
To: Gupta, Kshitij
Cc: Takashi Iwai; alsa-devel@lists.sourceforge.net
Subject: RE: FW: [Alsa-devel] DMA producer/consumer


On Fri, 12 Mar 2004, Gupta, Kshitij wrote:

> hi,
> 
> 	No no I was asking about the transfer of data from Application to
> the ring buffer (which is performed by ALSA middle layer),  let me reframe
> the doubt I have.  
> When we queue a next period to the DMA engine, we have no idea whether
data
> for the next period has been already filled up ( filled up means --> data
> filled up by Alsa middle layer , which is sent by the application ).  So
> before queueing a next period to the DMA engine we will have to check
> whether the ring buffer has sufficient data or not (because DMA will
> transfer even if it is empty).  And for that purpose we might need to use
> appl_ptr , which you said is a bad idea.
> 
> ps: the assumptions you said about small fifo and DMA engine are also true

Fine, I think that you didn't catch my point:

1) midlevel calls trigger(START)
   - the lowlevel driver enqueues two blocks (periods) to DMA engine here
2) dma engine starts to transfer first block (period)
3) dma engine finished to transfer first block (period) and triggered
   interrupt; dma engine start to transfer the second block automatically
   (because it was enqueued in trigger)
4) lowlevel driver calls snd_pcm_period_elapsed() in the interrupt handler
5) midlevel code decides in the snd_pcm_period_elapsed() if underrun 
   occured (no more data) and if this condition is true, trigger(STOP)
   callback is called and the lowlevel driver aborts the DMA operation
6) if midlevel code has enough data from application - no trigger callback
   is called
7) lowlevel driver should enqueue next DMA block (period) ahead - this 
   operation might be done in the start of interrupt handler before 
   snd_pcm_period_elapsed() is called

So, in this algorithm, there is only a very small time window between
the interrupt condition and aborting of the DMA transfer in the 
trigger(STOP) callback which is acceptable. Note that underruns or 
overruns (xruns in our terminology ;-)) are bad and should not happen
when the system has a good configuration. So a transfer of a few "wrong" 
samples is acceptable in this case.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
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

RE: FW: DMA producer/consumer

[Jaroslav Kysela]

On Fri, 12 Mar 2004, Gupta, Kshitij wrote:

> hi,
> 	:) maps almost perfectly ...thanx a lot.  Only other doubt I had
> was, why are we always getting underruns in case of ARM (as Russell also
> pointed out that there are some cache coherency problems), but I am not able
> to map cache coherency problems to the underruns we are getting.  We are
> getting underruns consistently, even with very small period size (about 1k).

I think that the problem must be somewhere else. Check the input data to 
the OSS layer. If you use OSS emulation, then the coherency problem does 
not exist, because appl_ptr and hw_ptr is updated only from the kernel 
space.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
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