Re: Plugin loading and unloading

[Marcel Holtmann <marcel@holtmann.org>]

Hi Jaroslav,

> > > > I am working again on the A2DP Bluetooth plugin and the caching support
> > > > in the latest ALSA library is nice and allows me to keep the underlaying
> > > > link connected while stupid programs like XMMS closes the PCM when they
> > > > switch the tracks.
> > > > 
> > > > The PCM opening part and reusing of the underlaying AVDTP connection is
> > > > easy, but I am a little bit concerned about the plugin unloading time.
> > > > So is it possible to add init() and exit() functions that are called
> > > > when the plugin is loaded and unloaded. Like we have for kernel modules?
> > > 
> > > Wouldn't be possible to use ((constructor)) and ((destructor)) function 
> > > attributes for this purpose?
> > 
> > I have no idea how. Do you have an example for me. I like to try it.
> 
> void snd_async_init(void) __attribute__ ((constructor));
> 
> void snd_async_init(void)
> {
> }

this is working fine. Any reason not to make them "static"?

> > > > Do the ALSA library has a timer mechanism that we can use inside a
> > > > plugin. Since it is a bad idea to hold the Bluetooth connection open for
> > > > all the time, I like to add a idle timeout. This allows me to put the
> > > > connection into sniff mode to save power or terminate it.
> > > 
> > > It's not possible to use any time resource using signals, because 
> > > applications might be using the signal for another purpose. It seems
> > > to me that the only possibility is to use fork() and code a little 
> > > watchdog or use threads.
> > 
> > I thought so for the signals, but can't ALSA provide somekind of other
> > timer mechanism for internal use?
> 
> alsa-lib has access to similar resources as plugin (because plugin is 
> called from alsa-lib). It might be possible to use an async notification 
> with the ALSA timer interface using the system timer, but this part has 
> not been finished in alsa-lib yet.

The question is when do you expect this to be ready? It would help a lot
if I can use an ALSA native framework for it, because using threads or
fork() doesn't look like a good idea to me.

> > > > Also the listing of plugins is still missing. I am fine with a general
> > > > or plugin specific flag to make its PCM visible.
> > > 
> > > Yes, I was evaluating all possibilities and the result is that we will 
> > > have a cache (configuration file) listing device names with short comments 
> > > which applications should offer to users in their GUI.
> > > 
> > > In this case, a configuration tool (alsactl as standard ALSA tool or 
> > > perhaps distribution specific) will check the installed and active plugins
> > > and create a list automagically which can be altered with advanced users
> > > later. Of course, the list won't be complete in any way, because 
> > > there are unlimited variations of virtual device names.
> > 
> > This looks fine to me. Will it in the 1.0.9 release?
> 
> I hope so..

Cool.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20