From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcel Holtmann Subject: Re: Plugin loading and unloading Date: Mon, 09 May 2005 11:07:22 +0200 Message-ID: <1115629642.8949.150.camel@pegasus> References: <1114266960.10706.30.camel@pegasus> <1115626583.8949.124.camel@pegasus> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: alsa-devel-admin@lists.sourceforge.net Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Jaroslav Kysela Cc: alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.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