[alsa-devel] Writing a new plugin for ALSA

[Takashi Iwai]

At Mon, 9 Jul 2007 17:29:17 +0530,
Nobin Mathew wrote:
> 
> Hi,
> 
> I am trying to write a new ALSA plugin, like dmix.
> 
> My intend is to give priority to streams, i will not do up sample and
> down sample as we do in the case of dmix.

A small correction: dmix won't do any up/down-sampling but requires
the fixed sample rate.  The up/downsampling is the job of rate
plugin.

> If we do up sample and down sample then I think it will take lot of cpu.
> 
> In my case I have three streams audio, bluetooth sco and Navigation sound data.
> 
> priority is audio < sco < Nav
> 
> audio rate is 44100hz, sco rate is 8000hz
> 
> when sco is up audio should pause playback and audio should continue
> when sco is finished. I dont want to do software mixing. Thats why I
> am trying to write this new plugin.
> 
> 
> Assume that audio is active first, then sco comes to active state. So
> what i will do is in the library i will put audio app in sleep(), and
> re-configure the pcm for sco. Once sco is finished i will re-configure
> pcm for audio again like wise.

It should depend on the running mode.  For example, sleeping in the
plugin is bad for apps that require non-blocking access.  OTOH, for
blocking mode, sleeping until the stream gets ready again is
reasonable behavior.  And, I don't know whether the pausing is really
the right choice.  When it's paused, the application has no way to
know what's going on there.

Maybe, returning -ESTRPIPE, which means suspend, would be a better
choice.  Then the app is supposed to do a proper work for resuming
(calling snd_pcm_resume(), etc).

> so my question is there any api in the alsa-lib to take a copy of pcm
> structures, so when audio comes back gain i can use these saved pcm
> conf to that.

The "copy" of PCM handle won't help for your scenario, I guess.
Because the status of PCM stream is changed, the old copy won't match
with the latest state.

> Is there any api in the alsa-lib to reset the pcm structure to
> initialized state, means state just after open.

I feel this is a kind of things that needs a tight connection with the
kernel-side implementation.  For example, the plugin controlled from
multiple processes isn't easy to implement.  dmix uses SYSV IPC for
some parts, but it's to be avoided as much as possible.


Takashi