[alsa-devel] [PATCH 0/2] Arcam AV Control Plugin Updates
Hi,
The following patches provide minor updates to the Arcam AV control plug-in.
* [PATCH 1/2] Remove incorrect usage of the static SHM ID variable * [PATCH 2/2] Refactor control specifications to facilitate addition of "numid" optimisation
Takashi,
I attempted to follow the pattern of your recent commits regarding the "numid" optimisations for external control plug-ins. Hopefully I've provided the correct behavior. Something that am not sure about is whether I should be calling the "snd_ctl_elem_id_set_numid()" function from "ctl_arcam_av.c" "arcam_av_read_event()" either in addition or instead of the calls to the "snd_ctl_elem_id_set_name()" function?
Thanks
Peter
At Sat, 21 Feb 2009 16:59:47 +0000, Peter Stokes wrote:
Hi,
The following patches provide minor updates to the Arcam AV control plug-in.
- [PATCH 1/2] Remove incorrect usage of the static SHM ID variable
- [PATCH 2/2] Refactor control specifications to facilitate addition of "numid" optimisation
Takashi,
I attempted to follow the pattern of your recent commits regarding the "numid" optimisations for external control plug-ins. Hopefully I've provided the correct behavior.
Thanks, applied now.
Something that am not sure about is whether I should be calling the "snd_ctl_elem_id_set_numid()" function from "ctl_arcam_av.c" "arcam_av_read_event()" either in addition or instead of the calls to the "snd_ctl_elem_id_set_name()" function?
Better to put both. The find_elem() should fill the id fields as much as possible in return.
Takashi
Hi,
I have a question on mmap. If I give my .info to be _MMAP and _MMAP_VALID. Will ALSA framework internally take care of mmap-ing the kernel buffer that has been pre-allocated in the .probe call? Do I need to do anything special to mmap a kernel buffer into user space? Just accessing the runtime->dma_area would allow me to access user data right?
Thanks, Harsha
At Mon, 23 Feb 2009 18:59:11 +0530, Harsha, Priya wrote:
Hi,
I have a question on mmap. If I give my .info to be _MMAP and _MMAP_VALID. Will ALSA framework internally take care of mmap-ing the kernel buffer that has been pre-allocated in the .probe call? Do I need to do anything special to mmap a kernel buffer into user space? Just accessing the runtime->dma_area would allow me to access user data right?
Yes. The buffers allocated via preallocator are supposed to be mmappable, so you can simply pass _MMAP* flag there.
Takashi
Thank you. Can I use .ack callback to know that the mmaped buffer has been filled by the user? How would I know how much the user has written into the buffer that time? Would I need to have the pointers calculated and tracked myself or is there a field in the structures that I can read and find out?
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Monday, February 23, 2009 8:57 PM To: Harsha, Priya Cc: alsa-devel@alsa-project.org Subject: Re: clarification on mmap
At Mon, 23 Feb 2009 18:59:11 +0530, Harsha, Priya wrote:
Hi,
I have a question on mmap. If I give my .info to be _MMAP and _MMAP_VALID. Will ALSA framework internally take care of mmap-ing the kernel buffer that has been pre-allocated in the .probe call? Do I need to do anything special to mmap a kernel buffer into user space? Just accessing the runtime->dma_area would allow me to access user data right?
Yes. The buffers allocated via preallocator are supposed to be mmappable, so you can simply pass _MMAP* flag there.
Takashi
At Mon, 23 Feb 2009 22:21:24 +0530, Harsha, Priya wrote:
Thank you. Can I use .ack callback to know that the mmaped buffer has been filled by the user?
Not really. It's just for explicit read/write modes.
How would I know how much the user has written into the buffer that time?
You can check appl_ptr at any time. This corresponds to the position the app has filled.
Takashi
Would I need to have the pointers calculated and tracked myself or is there a field in the structures that I can read and find out?
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Monday, February 23, 2009 8:57 PM To: Harsha, Priya Cc: alsa-devel@alsa-project.org Subject: Re: clarification on mmap
At Mon, 23 Feb 2009 18:59:11 +0530, Harsha, Priya wrote:
Hi,
I have a question on mmap. If I give my .info to be _MMAP and _MMAP_VALID. Will ALSA framework internally take care of mmap-ing the kernel buffer that has been pre-allocated in the .probe call? Do I need to do anything special to mmap a kernel buffer into user space? Just accessing the runtime->dma_area would allow me to access user data right?
Yes. The buffers allocated via preallocator are supposed to be mmappable, so you can simply pass _MMAP* flag there.
Takashi
Thanks Takashi. Then what would be the best way to know when the mmaped buffer has been filled. So that I can take action to send it to the hardware?
Should I use the runtime->control->appl_ptr or runtime->status->appl_ptr to get the position the app has filled?
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, February 24, 2009 12:55 AM To: Harsha, Priya Cc: alsa-devel@alsa-project.org Subject: Re: clarification on mmap
At Mon, 23 Feb 2009 22:21:24 +0530, Harsha, Priya wrote:
Thank you. Can I use .ack callback to know that the mmaped buffer has been filled by the user?
Not really. It's just for explicit read/write modes.
How would I know how much the user has written into the buffer that time?
You can check appl_ptr at any time. This corresponds to the position the app has filled.
Takashi
Would I need to have the pointers calculated and tracked myself or is there a field in the structures that I can read and find out?
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Monday, February 23, 2009 8:57 PM To: Harsha, Priya Cc: alsa-devel@alsa-project.org Subject: Re: clarification on mmap
At Mon, 23 Feb 2009 18:59:11 +0530, Harsha, Priya wrote:
Hi,
I have a question on mmap. If I give my .info to be _MMAP and _MMAP_VALID. Will ALSA framework internally take care of mmap-ing the kernel buffer that has been pre-allocated in the .probe call? Do I need to do anything special to mmap a kernel buffer into user space? Just accessing the runtime->dma_area would allow me to access user data right?
Yes. The buffers allocated via preallocator are supposed to be mmappable, so you can simply pass _MMAP* flag there.
Takashi
I have another question on the same.
What are the runtime->transfer_ack_begin and transfer_ack_end used for? Will this help me understand when the runtime->dma_area are updated be it MMAPed buffer or not.
Thanks, Harsha
-----Original Message----- From: alsa-devel-bounces@alsa-project.org [mailto:alsa-devel-bounces@alsa-project.org] On Behalf Of Harsha, Priya Sent: Tuesday, February 24, 2009 10:24 AM To: Takashi Iwai Cc: alsa-devel@alsa-project.org Subject: Re: [alsa-devel] clarification on mmap
Thanks Takashi. Then what would be the best way to know when the mmaped buffer has been filled. So that I can take action to send it to the hardware?
Should I use the runtime->control->appl_ptr or runtime->status->appl_ptr to get the position the app has filled?
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, February 24, 2009 12:55 AM To: Harsha, Priya Cc: alsa-devel@alsa-project.org Subject: Re: clarification on mmap
At Mon, 23 Feb 2009 22:21:24 +0530, Harsha, Priya wrote:
Thank you. Can I use .ack callback to know that the mmaped buffer has been filled by the user?
Not really. It's just for explicit read/write modes.
How would I know how much the user has written into the buffer that time?
You can check appl_ptr at any time. This corresponds to the position the app has filled.
Takashi
Would I need to have the pointers calculated and tracked myself or is there a field in the structures that I can read and find out?
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Monday, February 23, 2009 8:57 PM To: Harsha, Priya Cc: alsa-devel@alsa-project.org Subject: Re: clarification on mmap
At Mon, 23 Feb 2009 18:59:11 +0530, Harsha, Priya wrote:
Hi,
I have a question on mmap. If I give my .info to be _MMAP and _MMAP_VALID. Will ALSA framework internally take care of mmap-ing the kernel buffer that has been pre-allocated in the .probe call? Do I need to do anything special to mmap a kernel buffer into user space? Just accessing the runtime->dma_area would allow me to access user data right?
Yes. The buffers allocated via preallocator are supposed to be mmappable, so you can simply pass _MMAP* flag there.
Takashi
_______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
At Tue, 24 Feb 2009 10:43:54 +0530, Harsha, Priya wrote:
I have another question on the same.
What are the runtime->transfer_ack_begin and transfer_ack_end used for?
I don't know, too, why these were introduced :) It's nowhere used. We should remove them, I think.
Will this help me understand when the runtime->dma_area are updated be it MMAPed buffer or not.
No, they are callbacks called from snd_pcm_period_elapsed(). And snd_pcm_period_elapsed() is the function the driver must call to update the buffer.
Takashi
Thanks, Harsha
-----Original Message----- From: alsa-devel-bounces@alsa-project.org [mailto:alsa-devel-bounces@alsa-project.org] On Behalf Of Harsha, Priya Sent: Tuesday, February 24, 2009 10:24 AM To: Takashi Iwai Cc: alsa-devel@alsa-project.org Subject: Re: [alsa-devel] clarification on mmap
Thanks Takashi. Then what would be the best way to know when the mmaped buffer has been filled. So that I can take action to send it to the hardware?
Should I use the runtime->control->appl_ptr or runtime->status->appl_ptr to get the position the app has filled?
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, February 24, 2009 12:55 AM To: Harsha, Priya Cc: alsa-devel@alsa-project.org Subject: Re: clarification on mmap
At Mon, 23 Feb 2009 22:21:24 +0530, Harsha, Priya wrote:
Thank you. Can I use .ack callback to know that the mmaped buffer has been filled by the user?
Not really. It's just for explicit read/write modes.
How would I know how much the user has written into the buffer that time?
You can check appl_ptr at any time. This corresponds to the position the app has filled.
Takashi
Would I need to have the pointers calculated and tracked myself or is there a field in the structures that I can read and find out?
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Monday, February 23, 2009 8:57 PM To: Harsha, Priya Cc: alsa-devel@alsa-project.org Subject: Re: clarification on mmap
At Mon, 23 Feb 2009 18:59:11 +0530, Harsha, Priya wrote:
Hi,
I have a question on mmap. If I give my .info to be _MMAP and _MMAP_VALID. Will ALSA framework internally take care of mmap-ing the kernel buffer that has been pre-allocated in the .probe call? Do I need to do anything special to mmap a kernel buffer into user space? Just accessing the runtime->dma_area would allow me to access user data right?
Yes. The buffers allocated via preallocator are supposed to be mmappable, so you can simply pass _MMAP* flag there.
Takashi
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
At Tue, 24 Feb 2009 10:24:19 +0530, Harsha, Priya wrote:
Thanks Takashi. Then what would be the best way to know when the mmaped buffer has been filled. So that I can take action to send it to the hardware?
In the current ALSA design, mmap transfer is completely asynchronous. The driver doesn't take care when app_ptr is updated. It's checked only when the hw_ptr is updated in snd_pcm_period_elapsed(). So, in general, what the card driver needs is to provide the ISR calling snd_pcm_period_elapsed() appropriately and, if possible, to provide the accurate PCM pointer callback to give the updated hw_ptr.
In mmap mode, other any transfer to the hardware is supposed to be done by the hardware (DMA) more or less automatically. If you need to do it by yourself, mmap isn't always the right answer.
Should I use the runtime->control->appl_ptr or runtime->status->appl_ptr to get the position the app has filled?
appl_ptr exists only in runtime->control.
HTH,
Takashi
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, February 24, 2009 12:55 AM To: Harsha, Priya Cc: alsa-devel@alsa-project.org Subject: Re: clarification on mmap
At Mon, 23 Feb 2009 22:21:24 +0530, Harsha, Priya wrote:
Thank you. Can I use .ack callback to know that the mmaped buffer has been filled by the user?
Not really. It's just for explicit read/write modes.
How would I know how much the user has written into the buffer that time?
You can check appl_ptr at any time. This corresponds to the position the app has filled.
Takashi
Would I need to have the pointers calculated and tracked myself or is there a field in the structures that I can read and find out?
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Monday, February 23, 2009 8:57 PM To: Harsha, Priya Cc: alsa-devel@alsa-project.org Subject: Re: clarification on mmap
At Mon, 23 Feb 2009 18:59:11 +0530, Harsha, Priya wrote:
Hi,
I have a question on mmap. If I give my .info to be _MMAP and _MMAP_VALID. Will ALSA framework internally take care of mmap-ing the kernel buffer that has been pre-allocated in the .probe call? Do I need to do anything special to mmap a kernel buffer into user space? Just accessing the runtime->dma_area would allow me to access user data right?
Yes. The buffers allocated via preallocator are supposed to be mmappable, so you can simply pass _MMAP* flag there.
Takashi
The exact issue I am facing is - if the data is mmaped or not I would want to know that the dma_area is filled and how much is filled so that I can setup the dma to transfer it to the hardware.
Can you suggest a way to do this?
Will the following help?
1. If the data is not mmaped, can I setup the transfer in .ack call to transfer the data copied from dma_area to hardware? 2. If the data is mmaped; In the .pointer call back, I get the exact hw pointer of how much has been played out. Here can I setup another transfer from dma_area? 3. How can I know internally in the driver if the application has mmaped the buffer or using the method of sending user buffers?
Thanks, Harsha
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, February 24, 2009 12:16 PM To: Harsha, Priya Cc: alsa-devel@alsa-project.org Subject: Re: clarification on mmap
At Tue, 24 Feb 2009 10:24:19 +0530, Harsha, Priya wrote:
Thanks Takashi. Then what would be the best way to know when the mmaped buffer has been filled. So that I can take action to send it to the hardware?
In the current ALSA design, mmap transfer is completely asynchronous. The driver doesn't take care when app_ptr is updated. It's checked only when the hw_ptr is updated in snd_pcm_period_elapsed(). So, in general, what the card driver needs is to provide the ISR calling snd_pcm_period_elapsed() appropriately and, if possible, to provide the accurate PCM pointer callback to give the updated hw_ptr.
In mmap mode, other any transfer to the hardware is supposed to be done by the hardware (DMA) more or less automatically. If you need to do it by yourself, mmap isn't always the right answer.
Should I use the runtime->control->appl_ptr or runtime->status->appl_ptr to get the position the app has filled?
appl_ptr exists only in runtime->control.
HTH,
Takashi
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, February 24, 2009 12:55 AM To: Harsha, Priya Cc: alsa-devel@alsa-project.org Subject: Re: clarification on mmap
At Mon, 23 Feb 2009 22:21:24 +0530, Harsha, Priya wrote:
Thank you. Can I use .ack callback to know that the mmaped buffer has been filled by the user?
Not really. It's just for explicit read/write modes.
How would I know how much the user has written into the buffer that time?
You can check appl_ptr at any time. This corresponds to the position the app has filled.
Takashi
Would I need to have the pointers calculated and tracked myself or is there a field in the structures that I can read and find out?
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Monday, February 23, 2009 8:57 PM To: Harsha, Priya Cc: alsa-devel@alsa-project.org Subject: Re: clarification on mmap
At Mon, 23 Feb 2009 18:59:11 +0530, Harsha, Priya wrote:
Hi,
I have a question on mmap. If I give my .info to be _MMAP and _MMAP_VALID. Will ALSA framework internally take care of mmap-ing the kernel buffer that has been pre-allocated in the .probe call? Do I need to do anything special to mmap a kernel buffer into user space? Just accessing the runtime->dma_area would allow me to access user data right?
Yes. The buffers allocated via preallocator are supposed to be mmappable, so you can simply pass _MMAP* flag there.
Takashi
At Tue, 24 Feb 2009 13:15:53 +0530, Harsha, Priya wrote:
The exact issue I am facing is - if the data is mmaped or not I would want to know that the dma_area is filled and how much is filled so that I can setup the dma to transfer it to the hardware.
Can you suggest a way to do this?
Will the following help?
- If the data is not mmaped, can I setup the transfer in .ack call
to transfer the data copied from dma_area to hardware? 2. If the data is mmaped; In the .pointer call back, I get the exact hw pointer of how much has been played out. Here can I setup another transfer from dma_area? 3. How can I know internally in the driver if the application has mmaped the buffer or using the method of sending user buffers?
Well, before going further into your questions, let's make the hardware design ALSA PCM framework assumes.
First off, the hardware is supposed to transfer the data from the given buffer (RAM) to the hardware in the background (e.g. DMA). Usually, the driver sets up the transfer in prepare callback, give a go at trigger callback, then the hardware will keep feeding the data from the given ring-buffer to the hardware continuously without any action.
The driver sets up the "period". It's the time the driver is woken up, and usually triggered by a hardware IRQ. The ISR will then call snd_pcm_period_elapsed() so that PCM core will work the rest of the job (updating hwptr, waking up the sleepers, etc). Meanwhile, PCM core will ask the driver to return the current transfer position in the ring buffer via pointer callback. The driver is responsible for that.
That's all. In this implementation case, there is no difference between the RW and the mmap transfers. The difference is handled in the PCM core.
Note that there is no need to refer to appl_ptr in the driver side because the DMA transfer is done continuously in the ring buffer.
If your hardware behaves differently, there need some workarounds to adapt that. For example, usb-audio has an intermediate buffer to handle URBs continuously.
If you need to feed the sample data to the hardware manually, e.g. via loop, the above model doesn't work because the (mmapped) data can be written at any moment on the ring buffer. You can fake it, but it's not that perfect.
Now, please make clear how your hardware works, and what is required in addition to that...
Takashi
Thanks, Harsha
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, February 24, 2009 12:16 PM To: Harsha, Priya Cc: alsa-devel@alsa-project.org Subject: Re: clarification on mmap
At Tue, 24 Feb 2009 10:24:19 +0530, Harsha, Priya wrote:
Thanks Takashi. Then what would be the best way to know when the mmaped buffer has been filled. So that I can take action to send it to the hardware?
In the current ALSA design, mmap transfer is completely asynchronous. The driver doesn't take care when app_ptr is updated. It's checked only when the hw_ptr is updated in snd_pcm_period_elapsed(). So, in general, what the card driver needs is to provide the ISR calling snd_pcm_period_elapsed() appropriately and, if possible, to provide the accurate PCM pointer callback to give the updated hw_ptr.
In mmap mode, other any transfer to the hardware is supposed to be done by the hardware (DMA) more or less automatically. If you need to do it by yourself, mmap isn't always the right answer.
Should I use the runtime->control->appl_ptr or runtime->status->appl_ptr to get the position the app has filled?
appl_ptr exists only in runtime->control.
HTH,
Takashi
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, February 24, 2009 12:55 AM To: Harsha, Priya Cc: alsa-devel@alsa-project.org Subject: Re: clarification on mmap
At Mon, 23 Feb 2009 22:21:24 +0530, Harsha, Priya wrote:
Thank you. Can I use .ack callback to know that the mmaped buffer has been filled by the user?
Not really. It's just for explicit read/write modes.
How would I know how much the user has written into the buffer that time?
You can check appl_ptr at any time. This corresponds to the position the app has filled.
Takashi
Would I need to have the pointers calculated and tracked myself or is there a field in the structures that I can read and find out?
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Monday, February 23, 2009 8:57 PM To: Harsha, Priya Cc: alsa-devel@alsa-project.org Subject: Re: clarification on mmap
At Mon, 23 Feb 2009 18:59:11 +0530, Harsha, Priya wrote:
Hi,
I have a question on mmap. If I give my .info to be _MMAP and _MMAP_VALID. Will ALSA framework internally take care of mmap-ing the kernel buffer that has been pre-allocated in the .probe call? Do I need to do anything special to mmap a kernel buffer into user space? Just accessing the runtime->dma_area would allow me to access user data right?
Yes. The buffers allocated via preallocator are supposed to be mmappable, so you can simply pass _MMAP* flag there.
Takashi
participants (3)
-
Harsha, Priya -
Peter Stokes -
Takashi Iwai