RE: FW: [Alsa-devel] DMA producer/consumer
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:[EMAIL PROTECTED] Sent: Thursday, March 11, 2004 11:30 PM To: Takashi Iwai Cc: Gupta, Kshitij; [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
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 [EMAIL PROTECTED] 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=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: FW: [Alsa-devel] DMA producer/consumer
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:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 3:03 PM To: Gupta, Kshitij Cc: Takashi Iwai; [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
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 [EMAIL PROTECTED] 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=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: FW: [Alsa-devel] DMA producer/consumer
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:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 3:19 PM To: Gupta, Kshitij Cc: Takashi Iwai; [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
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 [EMAIL PROTECTED] 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=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: FW: [Alsa-devel] DMA producer/consumer
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:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 3:45 PM To: Gupta, Kshitij Cc: Takashi Iwai; [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: FW: [Alsa-devel] DMA producer/consumer
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 [EMAIL PROTECTED] 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=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: FW: [Alsa-devel] DMA producer/consumer
At Thu, 11 Mar 2004 09:30:31 +0530,
Gupta, Kshitij wrote:
Any comments on this would be really helpful...
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Gupta,
Kshitij
Sent: Wednesday, March 10, 2004 5:06 PM
To: [EMAIL PROTECTED]
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=1470alloc_id=3638op=click
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: FW: [Alsa-devel] DMA producer/consumer
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 [EMAIL PROTECTED] 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=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
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 [EMAIL PROTECTED] 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=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: FW: [Alsa-devel] DMA producer/consumer
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=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[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=1470alloc_id=3638op=click
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
FW: [Alsa-devel] DMA producer/consumer
Any comments on this would be really helpful...
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Gupta,
Kshitij
Sent: Wednesday, March 10, 2004 5:06 PM
To: [EMAIL PROTECTED]
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=1470alloc_id=3638op=click
___
Alsa-devel mailing list
[EMAIL PROTECTED]
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=1470alloc_id=3638op=click
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
