[alsa-devel] Writing a new plugin for ALSA

[Nobin Mathew]

On 7/10/07, Takashi Iwai <tiwai at 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
> > 1) 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.
>
> > 2) 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:
> > 1) All streams will open pcm with a priority. (Pre decided for the system)
> > 2) 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