[alsa-devel] Writing a new plugin for ALSA

[Nobin Mathew]

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 at suse.de> wrote:
> At Tue, 10 Jul 2007 18:24:18 +0530,
> Nobin Mathew wrote:
> >
> > 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.
>
> 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
>