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@xxxxxxx> wrote: > At Tue, 10 Jul 2007 18:24:18 +0530, > Nobin Mathew wrote: > > > > On 7/10/07, Takashi Iwai <tiwai@xxxxxxx> 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 > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
