RE: [Alsa-devel] problem while opening device
hi Jaroslav, This file is present. The only other thing which I wanted to bring into your notice is that the file system we are using is a busybox file system, with no bash. Instead it has smaller shell ash. Will that make a difference. And this file /usr/share/alsa/alsa.conf is only meant to be read ??? Some other points : - Alsa driver is statically loaded into the kernel. We are also able to see that /proc/asound directory is being populated correctly. - the /dev/snd nodes are like this hwC0D0 midiC0D1 midiC2D2 pcmC0D1p pcmC1D2c pcmC2D2p pcmC3D3c hwC0D1 midiC0D2 midiC2D3 pcmC0D2c pcmC1D2p pcmC2D3c pcmC3D3p hwC0D2 midiC0D3 midiC2D4 pcmC0D2p pcmC1D3c pcmC2D3p pcmC3D4c hwC0D3 midiC0D4 midiC2D5 pcmC0D3c pcmC1D3p pcmC2D4c pcmC3D4p hwC1D0 midiC0D5 midiC2D6 pcmC0D3p pcmC1D4c pcmC2D4p pcmC3D5c hwC1D1 midiC0D6 midiC2D7 pcmC0D4c pcmC1D4p pcmC2D5c pcmC3D5p hwC1D2 midiC0D7 midiC3D0 pcmC0D4p pcmC1D5c pcmC2D5p pcmC3D6c hwC1D3 midiC1D0 midiC3D1 pcmC0D5c pcmC1D5p pcmC2D6c pcmC3D6p hwC2D0 midiC1D1 midiC3D2 pcmC0D5p pcmC1D6c pcmC2D6p pcmC3D7c hwC2D1 midiC1D2 midiC3D3 pcmC0D6c pcmC1D6p pcmC2D7c pcmC3D7p hwC2D2 midiC1D3 midiC3D4 pcmC0D6p pcmC1D7c pcmC2D7p seq hwC2D3 midiC1D4 midiC3D5 pcmC0D7c pcmC1D7p pcmC3D0c timer Do some older versions use hw00 as nodes ??? - Is there a way around these aliases hw:0,0 like can;t we open the device without this alias ??? warm regards -kshitij -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jaroslav Kysela Sent: Tuesday, April 06, 2004 6:20 PM To: Pavana Sharma Cc: [EMAIL PROTECTED] Subject: Re: [Alsa-devel] problem while opening device On Tue, 6 Apr 2004, Pavana Sharma wrote: Hi, I am running a test application on my alsa driver for arm platform.Driver is statically built. The test application calls the snd_pcm_open. With device hw:0,0 At the target I have created sound driver files with snddevices.sh In /proc/asound i have the soundcard registered as card0 . Can anyone give ideas where can be the problem ..?? this is the error msg I am getting.. snip--- ALSA lib pcm.c:1947:(snd_pcm_open_noupdate) Unknown PCM hw:0,0 /usr/share/alsa/alsa.conf is missing. 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 --- 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: [Alsa-devel] buffer producer/consumer sync
hi, I was just curious to know about by when will we be having a proper reference driver for ARM . We are ready to help out from here if there are any issues. warm regards -kshitij -Original Message- From: Russell King [mailto:[EMAIL PROTECTED] Behalf Of Russell King Sent: Tuesday, March 09, 2004 5:17 PM To: Gupta, Kshitij Cc: Jaroslav Kysela; [EMAIL PROTECTED] Subject: Re: [Alsa-devel] buffer producer/consumer sync On Tue, Mar 09, 2004 at 05:03:37PM +0530, Gupta, Kshitij wrote: I was referring to a ARM implementation in the ALSA tree for our ALSA driver development on OMAP 1610 (ARM 926) sound\arm\sa11xx-uda1341.c. Just wanted to know if sa11xx-uda1341.c is also affected by this problem. sa11xx-uda1341 isn't a good driver to look at - it's very specific to the iPAQ as it stands. I've been working on a properly modularised driver which separates out the PCM DMA engine from the rest of the code, which in turn makes it a lot easier to add support for different platforms. IOW, I've done the job properly. However, just as the iPAQ people (didn't) work with the rest of the ARM community when they created their supposed generic sa11xx-uda1341 implementation, the rest of the ARM community didn't work with them when creating our driver. And now various people are calling for sa11xx-uda1341 to be deleted once my driver is merged. It's good when communities fragment, isn't it? 8( However, the problem I've been describing is a problem with the core ALSA implementation and affects all hardware drivers on ARM, whether they be PCI, ISA or ARM specific. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core --- 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] RE: compilation problem 3.4.0 gcc toolchain / armv6 / 2.6.0-rmk1 kernel
forgot to paste the error messeges sound/core/oss/pcm_plugin.c:34: internal compiler error: in loc_descriptor_from_tree, at dwarf2out.c:8800 Please submit a full bug report, with preprocessed source if appropriate. Send email to [EMAIL PROTECTED] for instructions. make[3]: *** [sound/core/oss/pcm_plugin.o] Error 1 make[2]: *** [sound/core/oss] Error 2 make[1]: *** [sound/core] Error 2 make: *** [sound] Error 2 -Original Message- From: Gupta, Kshitij Sent: Wednesday, March 31, 2004 12:13 PM To: [EMAIL PROTECTED] Subject: compilation problem 3.4.0 gcc toolchain / armv6 / 2.6.0-rmk1 kernel hi, I am getting errors while compiling 2.6.0-rmk1 kernel with 3.4.0 arm gcc tool chain, for armv6 architecture. Has anyone tried this before, or if anyone can suggest me a toolchain which can compile armv6 + ALSA. 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
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
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
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
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
[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
[Alsa-devel] buffer producer/consumer sync
Title: buffer producer/consumer sync
hi ,
While debugging my alsa driver , some observations...
The flow goes like this
- cat test.raw /dev/pcm
- Middle layer fills up the buffer (size = period_size). Why does middle layer only fills up period_size ??
- ...(open / init etc)
- Trigger with PLAY command is called
a) audio_dma_process routine is called
This routine starts a dma transfer for a size of period_size
b) We get a end of transfer interrupt and our callback is called. In the callback function we call snd_pcm_period_elapsed to notify that one period is finished. This function causes Trigger to be called again with STOP and then START again. And the reason which I found after much debugging is this :
--
if (avail = runtime-stop_threshold) {
snd_pcm_stop(substream,
runtime-status-state == SNDRV_PCM_STATE_DRAINING ?
SNDRV_PCM_STATE_SETUP : SNDRV_PCM_STATE_XRUN);
this code is a part of snd_pcm_update_hw_ptr_post function in sound/core/pcm_lib.c
--
avail value is coming equal to runtime-stop_threshold and that is why we are getting a stop. A trace of these values is :
initially
hw_ptr = 0 appl_ptr = period_size avail = runtime-buffersize stop_threshold = runtime-buffersize (this is set by default)
after one DMA transfer
hw_ptr = period_size appl_ptr = period_size(still the same value ... middle layer should have filled in more data and updated this )
avail = hw_ptr + runtime-buffersize - appl_ptr
so again avail = runtime-buffersize , since hw_ptr is equal to appl_ptr.
What we analyzed here is that After the DMA transfer starts and before the finish of the DMA transfer the alsa middle layer should fill up data from application layer (cat command in this context). So probably DMA transfer is happening at a much faster rate than the middle layer can fill up more application buffers.
Can someone comment on this and guide a little bit to solve this problem.
warm regards
-kshitij
RE: [Alsa-devel] buffer producer/consumer sync
hi, Just for your information we are using OSS PCM emulation. And let me also first understand the problem :). Which I am not able to figure out yet :(. regards -kshitij -Original Message- From: Russell King [mailto:[EMAIL PROTECTED] Behalf Of Russell King Sent: Tuesday, March 09, 2004 3:48 PM To: Jaroslav Kysela Cc: Gupta, Kshitij; [EMAIL PROTECTED] Subject: Re: [Alsa-devel] buffer producer/consumer sync On Tue, Mar 09, 2004 at 10:53:57AM +0100, Jaroslav Kysela wrote: On Tue, 9 Mar 2004, Gupta, Kshitij wrote: Can someone comment on this and guide a little bit to solve this problem. Yes, on ARM platform you might have problem with MMU / cache coherency, because appl_ptr and hw_ptr are mmaped to user space. I observed this behaviour on SA11xx platform, too. Russell King already notified us about this problem. See the mail archive for the proper fix of the midlevel code. There currently doesn't exist a public fix for this yet, so people using ARM platforms will have to live without ALSA for the time being. (Actually, you can still use ALSA but you must use OSS PCM emulation.) As you say, appl_ptr and hw_ptr have cache coherency problems. However, a portable and acceptable solution does not exist today to solve this problem which would be acceptable to ALSA. The current preferred solution is to call flush_dcache_page() on the page whenever the kernel reads and writes such a page - obviously that is too expensive for ALSA. Therefore, kernel architecture people need to trash this issue out, but I'm only interested in doing that post-2.6.4, once we've managed to get the DMA mapping stuff sorted properly. Unfortunately I'm busy for the next three days with other stuff, so I won't be able to look at any of this; I doubt 2.6.4 will be out before Friday morning anyway. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core --- 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: [Alsa-devel] buffer producer/consumer sync
hi, I was referring to a ARM implementation in the ALSA tree for our ALSA driver development on OMAP 1610 (ARM 926) sound\arm\sa11xx-uda1341.c. Just wanted to know if sa11xx-uda1341.c is also affected by this problem. regards -kshitij -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Gupta, Kshitij Sent: Tuesday, March 09, 2004 4:11 PM To: 'Russell King'; Jaroslav Kysela Cc: [EMAIL PROTECTED] Subject: RE: [Alsa-devel] buffer producer/consumer sync hi, Just for your information we are using OSS PCM emulation. And let me also first understand the problem :). Which I am not able to figure out yet :(. regards -kshitij -Original Message- From: Russell King [mailto:[EMAIL PROTECTED] Behalf Of Russell King Sent: Tuesday, March 09, 2004 3:48 PM To: Jaroslav Kysela Cc: Gupta, Kshitij; [EMAIL PROTECTED] Subject: Re: [Alsa-devel] buffer producer/consumer sync On Tue, Mar 09, 2004 at 10:53:57AM +0100, Jaroslav Kysela wrote: On Tue, 9 Mar 2004, Gupta, Kshitij wrote: Can someone comment on this and guide a little bit to solve this problem. Yes, on ARM platform you might have problem with MMU / cache coherency, because appl_ptr and hw_ptr are mmaped to user space. I observed this behaviour on SA11xx platform, too. Russell King already notified us about this problem. See the mail archive for the proper fix of the midlevel code. There currently doesn't exist a public fix for this yet, so people using ARM platforms will have to live without ALSA for the time being. (Actually, you can still use ALSA but you must use OSS PCM emulation.) As you say, appl_ptr and hw_ptr have cache coherency problems. However, a portable and acceptable solution does not exist today to solve this problem which would be acceptable to ALSA. The current preferred solution is to call flush_dcache_page() on the page whenever the kernel reads and writes such a page - obviously that is too expensive for ALSA. Therefore, kernel architecture people need to trash this issue out, but I'm only interested in doing that post-2.6.4, once we've managed to get the DMA mapping stuff sorted properly. Unfortunately I'm busy for the next three days with other stuff, so I won't be able to look at any of this; I doubt 2.6.4 will be out before Friday morning anyway. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core --- 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
[Alsa-devel] runtime-dma_addr
hi, Can someone please explain me what is the difference between runtime-dma_addr and runtime-dma_area where runtime = substream-runtime I am getting a very strange problem where I am getting a rumtime-dma_addr value as 0 while runtime-dma_area is a proper value. Any hints will be helpful warm regards -kshitij --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] Dma query
hi, Any insights will be really helpful :) . regards -kshitij -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Gupta, Kshitij Sent: Wednesday, February 25, 2004 4:59 PM To: 'Jaroslav Kysela' Cc: [EMAIL PROTECTED] Subject: RE: [Alsa-devel] Dma query hi , That's correct the pages will be in whole meory space and I will be using snd_pcm_lib_preallocate_pages_for_all api for allocating the space. There are some DMA apis (for our dma framework) like set_dma_transfer_params(srcaddr, destaddr, mode ...) Now I need to call this API whenever the transmit for one of the buffers is complete. Or is it like, these things should be done just once upfront. But that means we need n channels if we want n buffers to be ring buffers. regards -kshitij -Original Message- From: Jaroslav Kysela [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 25, 2004 4:05 PM To: Gupta, Kshitij Cc: [EMAIL PROTECTED] Subject: Re: [Alsa-devel] Dma query On Wed, 25 Feb 2004, Gupta, Kshitij wrote: hi, I have a very trivial question about the dma transfers with respect to ALSA framework. Let me first explain a scenario We have a Circularly linked Buffer pool buf1buf2buf3 buf4 bufn In very simple terms playing an audio stream is reading from these buffers and continuously dma'ing it to the audio device (let's assume we have a read and write register with the audio device). And in this circulary linked audio buffer the user fills the data and the driver empties it to the device. Now I am not able to fit this scenario in the ALSA framework. I am referrring to alsa-kernel/arm/sa11xx-uda1341.c file as a reference for my driver. And here I don't understand where do we specify the the exact dma parameters (like the start address of buffer and the destination address). DMA buffer is allocated hw_params callback. It depends, how the DMA pages have to be allocated. You didn't write any details. If pages can be in the whole memory space (from the view of CPU and DMA controller), then we have SNDRV_DMA_TYPE_CONTINUOUS for it (use snd_pcm_lib_preallocate_pages_for_all at init and standard functions like in other drivers in hw_params and hw_free callbacks). Jaroslav - Jaroslav Kysela [EMAIL PROTECTED] Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] Dma query
Hi, So does that mean that the __next period__ DMA transfer parameters should be set in the interrupt routine(end of transfer of one period). But to set the next DMA transfer params we must know the start address of the buffer which the middle layer has filled (and if the middle layer has filled up more than one buffers then this buffer should be at the head of the list). Also one more point is that the hardware provides us the mechanism of linking the DMA channels ( linking means that once one dma channel finishes the transfer other one starts automatically). So this feature provides us the facility of queuing up the DMA transfers. regards -kshitij ps: one more nasty question I wanted to ask on the list was about how much time does it take to write a driver(from scratch) with such a complex framework ;)...probably just sharing experiences regards -kshitij -Original Message- From: Jaroslav Kysela [mailto:[EMAIL PROTECTED] Sent: Thursday, February 26, 2004 4:57 PM To: Gupta, Kshitij Cc: [EMAIL PROTECTED] Subject: RE: [Alsa-devel] Dma query On Thu, 26 Feb 2004, Gupta, Kshitij wrote: hi , That's correct the pages will be in whole meory space and I will be using snd_pcm_lib_preallocate_pages_for_all api for allocating the space. There are some DMA apis (for our dma framework) like set_dma_transfer_params(srcaddr, destaddr, mode ...) Now I need to call this API whenever the transmit for one of the buffers is complete. Or is it like, these things should be done just once upfront. But that means we need n channels if we want n buffers to be ring buffers. The ALSA midlevel expects if trigger callback is called, then the data starts the transfer from the allocated ring buffer (which is filled by the ALSA midlevel code or application - mmap mode). It's not necessary that ring buffer is continous from the physical memory perspective, but it must be continuous from the user space perspective (using MMU and page mapping). Then after one period transfer is finished, you need to call period_elapsed() callback from the interrupt to notify ALSA midlevel code about this situation and continue with the DMA transfer (next period). Note that the pointer callback must give the actual pointer in the ring buffer at this point. I hope this helps. Jaroslav - Jaroslav Kysela [EMAIL PROTECTED] Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Dma query
hi, I have a very trivial question about the dma transfers with respect to ALSA framework. Let me first explain a scenario We have a Circularly linked Buffer pool buf1buf2buf3 buf4 bufn In very simple terms playing an audio stream is reading from these buffers and continuously dma'ing it to the audio device (let's assume we have a read and write register with the audio device). And in this circulary linked audio buffer the user fills the data and the driver empties it to the device. Now I am not able to fit this scenario in the ALSA framework. I am referrring to alsa-kernel/arm/sa11xx-uda1341.c file as a reference for my driver. And here I don't understand where do we specify the the exact dma parameters (like the start address of buffer and the destination address). Can someone enlighten me on this or else suggest me some other reference driver. regards -kshitij --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] Dma query
Thanx for the detailslet me just figure out the full flow and then come with some more queries ;)... -Original Message- From: Giuliano Pochini [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 25, 2004 4:23 PM To: Gupta, Kshitij Cc: [EMAIL PROTECTED] Subject: Re: [Alsa-devel] Dma query On Wed, 25 Feb 2004, Gupta, Kshitij wrote: hi, I have a very trivial question about the dma transfers with respect to ALSA framework. Let me first explain a scenario We have a Circularly linked Buffer pool buf1buf2buf3 buf4 bufn In very simple terms playing an audio stream is reading from these buffers and continuously dma'ing it to the audio device (let's assume we have a read and write register with the audio device). And in this circulary linked audio buffer the user fills the data and the driver empties it to the device. Now I am not able to fit this scenario in the ALSA framework. I am referrring to alsa-kernel/arm/sa11xx-uda1341.c file as a reference for my driver. And here I don't understand where do we specify the the exact dma parameters (like the start address of buffer and the destination address). You should do most of the hw setup in the .hw_params callback. You get pointers to the substream and hw_params structures and you have to setup the hw and the buffer as requested. These macros may be useful params_period_bytes(), params_buffer_bytes(), snd_pcm_substream_sgbuf(), snd_sgbuf_get_addr(). There are many others, look at the sources :) -- Giuliano. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] new alsa driver for ti omap chip
hi,
yeah that's true I2S has not much to with the driver. So there is
one more component on the chip called McBSP(Multichannel Buffered serial
port) which will actually communicate to the codec chip over I2S protocol.
And the DMA can read data from the McBSP recieve and transmit buffers. But
still the driver has to do the McBSP configuration.
The kind of functionality the driver should provide is
- Codec Control
xxx_codec_write
xxx_codec_read
for reading and writing to the codec control bits. This will be done via
SPI interface.
- Dma Control functions
start_dma
queue_dma
stop_dma ...
And all the ALSA based functions for init, read , write etc.
regards
-kshitij
-Original Message-
From: Jaroslav Kysela [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 12, 2004 4:53 PM
To: Takashi Iwai
Cc: Gupta, Kshitij; '[EMAIL PROTECTED]'
Subject: Re: [Alsa-devel] new alsa driver for ti omap chip
On Thu, 12 Feb 2004, Takashi Iwai wrote:
At Thu, 12 Feb 2004 12:56:04 +0530,
Gupta, Kshitij wrote:
hi,
I am trying to write an alsa driver for a tsc2101 codec on a arm
based SOC. The control interface between the SOC and the tsc2101 codec
is
via SPI.
And the data interface is a I2S interface. Can some one suggest a good
starting point to start such a driver.
some ALSA drivers use their own i2c functions, although there is a
generic i2c layer on linux kernel. for example, delta.c or ews.c of
ice1712 driver use i2c (SPI) transfer (which calls ak4xxx-adda.c).
but it's rather complex to refer...
the i2c transfer is really easy to implement. do just like the spec
says. a pseudo code is like below.
chip_select_low();
udelay(1);
for (i = 15; i = 0; i--) {
set_bit_clock(0);
udelay(1);
if (value_to_send (1 i))
set_bit_data(1);
else
set_bit_data(0);
udelay(1);
set_bit_clock(0);
udelay(1);
}
chip_select_high();
Note that I2S is not I2C. I2S is used to connect A/D and D/A converters
(three wires - clock, l/r word and sample bit). We don't talk directly
with any device over this serial bus.
I think that the driver must be written for a sound bridge between host
and the converters. In case of ARM platform, it's usually an integrated
serial controller which can do DMA transfers.
So, this I2S question is a bit irrelevant (it's for hardware designers,
but not for driver developers).
Because I don't know the behaviour of the sound / serial bridge, I cannot
suggest a driver, but if it's similar as ARM1100 architecture, then we
have already a driver for it.
Jaroslav
-
Jaroslav Kysela [EMAIL PROTECTED]
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] new alsa driver for ti omap chip
hi, I am trying to write an alsa driver for a tsc2101 codec on a arm based SOC. The control interface between the SOC and the tsc2101 codec is via SPI. And the data interface is a I2S interface. Can some one suggest a good starting point to start such a driver. does sound/drivers/dummy.c makes sense for such a driver ??? warm regards -kshitij --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
