Re: [alsa-devel] Writing a new plugin for ALSA
On 7/10/07, Takashi Iwai tiwai@suse.de wrote:
At Tue, 10 Jul 2007 17:45:03 +0530, Sudhanshu Saxena wrote:
Hi Takashi,
I am working on this issue along with Nobin, for multiple multiple streams (at different rates) playback based on a priority.
I attempted suspend and resume returning -ESTRPIPE, but it has two issues
- All applications may need a change in Suspend logic specific to wait for higher
priority stream to run to completion.
Basically every app is _required_ to handle of suspend/resume properly.
- I have to still find out a mechanism to reset the hardware settings are reconfigure
it for second stream. snd_pcm_hw_reset has an access to reset using IOCTL "SNDRV_PCM_IOCTL_RESET" , I hope that can help, I am not very sure on this.
Well, I don't think the plugin itself requires the reset.
As mentioned by Nobin we want to skip any upsampling caused when we use the dmix (rate) plugin. I was trying to find the way out, with a plugin with following changes:
- All streams will open pcm with a priority. (Pre decided for the system)
- Plug-in will have shared memory to hold the priority list of all applications which
are accessing sound. 3) At any instance only one stream will be active. 4) All applications will hold the context of HW params and SW params (accessible through apis plugin will support). 5) If an application with a higher priority calls snd_pcm_open shared memory with the priority list will be updated and when the currently active stream attempts to re-write the data it will check for priority list. This will cause saving of params, drain of stream and reset of hw as mentioned using above IOCTL and the active stream would be changed to currently highest in the priority list. 6) The higher priority stream can then start writing data, on completion of access similar sequence of drain, hw reset will be caused and the active stream will be changed to next in the priority list. 7) On resume of lower priority stream the hw params will be set again.
The question is how the application decides which stream to use. If it can open a PCM with a different name (to snd_pcm_open call), and if you have three individual PCM devices, the whole switching can be done inside the kernel driver. That is, when an SCO stream is opened during audio stream(s) is running, the driver triggers SUSPEND mode for the audio stream. Then the app will stop and restart the stream by itself. This means you don't need any change in user-space side but needs some additions in the driver side.
We thought about implementing this in the kernel driver, but after some investigation, we found that we are serializing the driver so much by providing three interfaces (audio, sco and Nav). say pcmC0D0p/c, pcmC0D1p/c and pcmC0D2p/c.
Consider the case of two apps audio and sco. We have two interfaces for this pcmC0D0p/c and pcmC0D1p/c priority is audio < sco
so interface priority is pcmC0D0p/c < pcmC0D1p/c.
Assume that audio is already opened. When we open sco interface audio interface can be in any state, it i can be in paused state or it is about to close etc. So we will have so many states of application in the kernel driver.
we need to maintain all these states of application in the kernel driver. Say tomorrow one more application came in to picture, then this complexity will increase.
Locking of states of streams is also required in this case.
correct me if I am going wrong
BTW, any reason to drop Cc to alsa-devel ML? Such an open discussion is very important for opensource development.
I think Sudhanshu missed it, I am copying to alsa-devel
Takashi
thanks Nobin mathew
At Tue, 10 Jul 2007 18:24:18 +0530, Nobin Mathew wrote:
On 7/10/07, Takashi Iwai tiwai@suse.de wrote:
At Tue, 10 Jul 2007 17:45:03 +0530, Sudhanshu Saxena wrote:
Hi Takashi,
I am working on this issue along with Nobin, for multiple multiple streams (at different rates) playback based on a priority.
I attempted suspend and resume returning -ESTRPIPE, but it has two issues
- All applications may need a change in Suspend logic specific to wait for higher
priority stream to run to completion.
Basically every app is _required_ to handle of suspend/resume properly.
- I have to still find out a mechanism to reset the hardware settings are reconfigure
it for second stream. snd_pcm_hw_reset has an access to reset using IOCTL "SNDRV_PCM_IOCTL_RESET" , I hope that can help, I am not very sure on this.
Well, I don't think the plugin itself requires the reset.
As mentioned by Nobin we want to skip any upsampling caused when we use the dmix (rate) plugin. I was trying to find the way out, with a plugin with following changes:
- All streams will open pcm with a priority. (Pre decided for the system)
- Plug-in will have shared memory to hold the priority list of all applications which
are accessing sound. 3) At any instance only one stream will be active. 4) All applications will hold the context of HW params and SW params (accessible through apis plugin will support). 5) If an application with a higher priority calls snd_pcm_open shared memory with the priority list will be updated and when the currently active stream attempts to re-write the data it will check for priority list. This will cause saving of params, drain of stream and reset of hw as mentioned using above IOCTL and the active stream would be changed to currently highest in the priority list. 6) The higher priority stream can then start writing data, on completion of access similar sequence of drain, hw reset will be caused and the active stream will be changed to next in the priority list. 7) On resume of lower priority stream the hw params will be set again.
The question is how the application decides which stream to use. If it can open a PCM with a different name (to snd_pcm_open call), and if you have three individual PCM devices, the whole switching can be done inside the kernel driver. That is, when an SCO stream is opened during audio stream(s) is running, the driver triggers SUSPEND mode for the audio stream. Then the app will stop and restart the stream by itself. This means you don't need any change in user-space side but needs some additions in the driver side.
We thought about implementing this in the kernel driver, but after some investigation, we found that we are serializing the driver so much by providing three interfaces (audio, sco and Nav). say pcmC0D0p/c, pcmC0D1p/c and pcmC0D2p/c.
Consider the case of two apps audio and sco. We have two interfaces for this pcmC0D0p/c and pcmC0D1p/c priority is audio < sco
so interface priority is pcmC0D0p/c < pcmC0D1p/c.
Assume that audio is already opened. When we open sco interface audio interface can be in any state, it i can be in paused state or it is about to close etc. So we will have so many states of application in the kernel driver.
Well, but this is same for user-space solution.
How the exclusiveness is handled in the driver? What exactly happens if you open two different streams (e.g. audio and sco) at the same time? Does it return an error?
we need to maintain all these states of application in the kernel driver. Say tomorrow one more application came in to picture, then this complexity will increase.
Locking of states of streams is also required in this case.
It's needed in any case if the concurrent access is possible.
Takashi
If I open both sco and audio simultaneously, where I will push the data from both streams, because I have only one codec, i.e. single DAC/ADC pair.
So that needs stopping one of the stream inside the kernel.
When we try to stop one stream from kernel itself, it will lead to problems I mentioned in the earlier mail.
Thanks Nobin Mathew
On 7/10/07, Takashi Iwai tiwai@suse.de wrote:
At Tue, 10 Jul 2007 18:24:18 +0530, Nobin Mathew wrote:
On 7/10/07, Takashi Iwai tiwai@suse.de wrote:
At Tue, 10 Jul 2007 17:45:03 +0530, Sudhanshu Saxena wrote:
Hi Takashi,
I am working on this issue along with Nobin, for multiple multiple streams (at different rates) playback based on a priority.
I attempted suspend and resume returning -ESTRPIPE, but it has two issues
- All applications may need a change in Suspend logic specific to wait for higher
priority stream to run to completion.
Basically every app is _required_ to handle of suspend/resume properly.
- I have to still find out a mechanism to reset the hardware settings are reconfigure
it for second stream. snd_pcm_hw_reset has an access to reset using IOCTL "SNDRV_PCM_IOCTL_RESET" , I hope that can help, I am not very sure on this.
Well, I don't think the plugin itself requires the reset.
As mentioned by Nobin we want to skip any upsampling caused when we use the dmix (rate) plugin. I was trying to find the way out, with a plugin with following changes:
- All streams will open pcm with a priority. (Pre decided for the system)
- Plug-in will have shared memory to hold the priority list of all applications which
are accessing sound. 3) At any instance only one stream will be active. 4) All applications will hold the context of HW params and SW params (accessible through apis plugin will support). 5) If an application with a higher priority calls snd_pcm_open shared memory with the priority list will be updated and when the currently active stream attempts to re-write the data it will check for priority list. This will cause saving of params, drain of stream and reset of hw as mentioned using above IOCTL and the active stream would be changed to currently highest in the priority list. 6) The higher priority stream can then start writing data, on completion of access similar sequence of drain, hw reset will be caused and the active stream will be changed to next in the priority list. 7) On resume of lower priority stream the hw params will be set again.
The question is how the application decides which stream to use. If it can open a PCM with a different name (to snd_pcm_open call), and if you have three individual PCM devices, the whole switching can be done inside the kernel driver. That is, when an SCO stream is opened during audio stream(s) is running, the driver triggers SUSPEND mode for the audio stream. Then the app will stop and restart the stream by itself. This means you don't need any change in user-space side but needs some additions in the driver side.
We thought about implementing this in the kernel driver, but after some investigation, we found that we are serializing the driver so much by providing three interfaces (audio, sco and Nav). say pcmC0D0p/c, pcmC0D1p/c and pcmC0D2p/c.
Consider the case of two apps audio and sco. We have two interfaces for this pcmC0D0p/c and pcmC0D1p/c priority is audio < sco
so interface priority is pcmC0D0p/c < pcmC0D1p/c.
Assume that audio is already opened. When we open sco interface audio interface can be in any state, it i can be in paused state or it is about to close etc. So we will have so many states of application in the kernel driver.
Well, but this is same for user-space solution.
How the exclusiveness is handled in the driver? What exactly happens if you open two different streams (e.g. audio and sco) at the same time? Does it return an error?
we need to maintain all these states of application in the kernel driver. Say tomorrow one more application came in to picture, then this complexity will increase.
Locking of states of streams is also required in this case.
It's needed in any case if the concurrent access is possible.
Takashi
I think if we can a find/develop a solution inside the ALSA framework, then that will be usefull for lot of people. Because most of the new embedded devices are coming with GPS, bluetooth and Audio capabilities.
Thanks Nobin Mathew
On 7/11/07, Nobin Mathew nobin.mathew@gmail.com wrote:
If I open both sco and audio simultaneously, where I will push the data from both streams, because I have only one codec, i.e. single DAC/ADC pair.
So that needs stopping one of the stream inside the kernel.
When we try to stop one stream from kernel itself, it will lead to problems I mentioned in the earlier mail.
Thanks Nobin Mathew
On 7/10/07, Takashi Iwai tiwai@suse.de wrote:
At Tue, 10 Jul 2007 18:24:18 +0530, Nobin Mathew wrote:
On 7/10/07, Takashi Iwai tiwai@suse.de wrote:
At Tue, 10 Jul 2007 17:45:03 +0530, Sudhanshu Saxena wrote:
Hi Takashi,
I am working on this issue along with Nobin, for multiple multiple streams (at different rates) playback based on a priority.
I attempted suspend and resume returning -ESTRPIPE, but it has two issues
- All applications may need a change in Suspend logic specific to wait for higher
priority stream to run to completion.
Basically every app is _required_ to handle of suspend/resume properly.
- I have to still find out a mechanism to reset the hardware settings are reconfigure
it for second stream. snd_pcm_hw_reset has an access to reset using IOCTL "SNDRV_PCM_IOCTL_RESET" , I hope that can help, I am not very sure on this.
Well, I don't think the plugin itself requires the reset.
As mentioned by Nobin we want to skip any upsampling caused when we use the dmix (rate) plugin. I was trying to find the way out, with a plugin with following changes:
- All streams will open pcm with a priority. (Pre decided for the system)
- Plug-in will have shared memory to hold the priority list of all applications which
are accessing sound. 3) At any instance only one stream will be active. 4) All applications will hold the context of HW params and SW params (accessible through apis plugin will support). 5) If an application with a higher priority calls snd_pcm_open shared memory with the priority list will be updated and when the currently active stream attempts to re-write the data it will check for priority list. This will cause saving of params, drain of stream and reset of hw as mentioned using above IOCTL and the active stream would be changed to currently highest in the priority list. 6) The higher priority stream can then start writing data, on completion of access similar sequence of drain, hw reset will be caused and the active stream will be changed to next in the priority list. 7) On resume of lower priority stream the hw params will be set again.
The question is how the application decides which stream to use. If it can open a PCM with a different name (to snd_pcm_open call), and if you have three individual PCM devices, the whole switching can be done inside the kernel driver. That is, when an SCO stream is opened during audio stream(s) is running, the driver triggers SUSPEND mode for the audio stream. Then the app will stop and restart the stream by itself. This means you don't need any change in user-space side but needs some additions in the driver side.
We thought about implementing this in the kernel driver, but after some investigation, we found that we are serializing the driver so much by providing three interfaces (audio, sco and Nav). say pcmC0D0p/c, pcmC0D1p/c and pcmC0D2p/c.
Consider the case of two apps audio and sco. We have two interfaces for this pcmC0D0p/c and pcmC0D1p/c priority is audio < sco
so interface priority is pcmC0D0p/c < pcmC0D1p/c.
Assume that audio is already opened. When we open sco interface audio interface can be in any state, it i can be in paused state or it is about to close etc. So we will have so many states of application in the kernel driver.
Well, but this is same for user-space solution.
How the exclusiveness is handled in the driver? What exactly happens if you open two different streams (e.g. audio and sco) at the same time? Does it return an error?
we need to maintain all these states of application in the kernel driver. Say tomorrow one more application came in to picture, then this complexity will increase.
Locking of states of streams is also required in this case.
It's needed in any case if the concurrent access is possible.
Takashi
participants (2)
-
Nobin Mathew -
Takashi Iwai