Plugin loading and unloading

Plugin loading and unloading

[Marcel Holtmann]

Hi guys,

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?

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.

Also the listing of plugins is still missing. I am fine with a general
or plugin specific flag to make its PCM visible.

Regards

Marcel




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Plugin loading and unloading

[Marcel Holtmann]

Hi again,

> 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?

is it possible to get comments on this?

> 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.

I really need to use a timer inside my ALSA plugin. How do it do it?

> Also the listing of plugins is still missing. I am fine with a general
> or plugin specific flag to make its PCM visible.

Looks like the 1.0.9-rc3 is coming and this won't be part of it :(

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

Re: Plugin loading and unloading

[Jaroslav Kysela]

On Sat, 23 Apr 2005, Marcel Holtmann wrote:

> Hi guys,
> 
> 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?

> 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.

> 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.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
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

Re: Plugin loading and unloading

[Marcel Holtmann]

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.

> > 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?

> > 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?

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

Re: Plugin loading and unloading

[Jaroslav Kysela]

On Mon, 9 May 2005, Marcel Holtmann wrote:

> 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)
{
}

> > > 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.

> > > 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..

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
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

Re: Plugin loading and unloading

[Marcel Holtmann]

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

Device name lists

[Jaroslav Kysela]

Hi all,

	I've added the functions handling device name list to alsa-lib.
Because alsa-lib open functions handle virtual names, it's impossible to
get list of all possible device names. The interface is:

typedef struct snd_devname snd_devname_t;

struct snd_devname {
        char *name;
        char *comment;
        snd_devname_t *next;
};

int snd_names_list(const char *interface, snd_devname_t **list);
void snd_names_list_free(snd_devname_t *list);

	As you can see, it simple as possible. The applications might 
request for a device list which can be generated automagically or advanced
users might create their own lists.
	The lookup is this:

1) file specified with ALSA_NAMES_FILE environment variable
2) ~/.asoundnm
3) /etc/asound.names

	Note that 2) and 3) files are not merged (only one file is 
parsed)!!! The syntax of these files is quite straighforward (alsa-lib
keeps the order of device compounds):

timer {
        alsactl1 {
                name 'hw:CLASS=1,SCLASS=0,CARD=-1,DEV=0,SUBDEV=0'
                comment 'Physical Device - system timer'
        }
}

	The alsactl tool was extended to generate a basic set of
device names (might be extended to detect other plugins as well). This 
command will generate /etc/asound.names file:

	alsactl names

To generate the user file use:

	alsactl -f ~/.asoundnm names


It's still time to do any changes and I would really appreciate 
comments...

The API is indended mainly for GUI applications or as a source of 
information for command line tools.

The aplay/arecord tool has now '-n' option which allows listing
of device names using this new API.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click

Re: Device name lists

[Marcel Holtmann]

Hi Jaroslav,

> 	I've added the functions handling device name list to alsa-lib.
> Because alsa-lib open functions handle virtual names, it's impossible to
> get list of all possible device names. The interface is:
> 
> typedef struct snd_devname snd_devname_t;
> 
> struct snd_devname {
>         char *name;
>         char *comment;
>         snd_devname_t *next;
> };
> 
> int snd_names_list(const char *interface, snd_devname_t **list);
> void snd_names_list_free(snd_devname_t *list);
> 
> 	As you can see, it simple as possible. The applications might 
> request for a device list which can be generated automagically or advanced
> users might create their own lists.
> 	The lookup is this:
> 
> 1) file specified with ALSA_NAMES_FILE environment variable
> 2) ~/.asoundnm
> 3) /etc/asound.names
> 
> 	Note that 2) and 3) files are not merged (only one file is 
> parsed)!!! The syntax of these files is quite straighforward (alsa-lib
> keeps the order of device compounds):
> 
> timer {
>         alsactl1 {
>                 name 'hw:CLASS=1,SCLASS=0,CARD=-1,DEV=0,SUBDEV=0'
>                 comment 'Physical Device - system timer'
>         }
> }
> 
> 	The alsactl tool was extended to generate a basic set of
> device names (might be extended to detect other plugins as well). This 
> command will generate /etc/asound.names file:
> 
> 	alsactl names
> 
> To generate the user file use:
> 
> 	alsactl -f ~/.asoundnm names
> 
> 
> It's still time to do any changes and I would really appreciate 
> comments...

this is prefect and I hope that the ALSA library users adapt this very
soon, but two questions came to my mind:

1) What is the reason for not merging /etc/asound.names and ~/.asoundnm?

2) Is another config file really needed? Why not add another parameter
called "name" to the current config file. So that I can simply create
this entry for my Bluetooth headphone from HP:

	pcm.hp {
	        type a2dp
	        name "HP stereo headphone"
	        bdaddr "00:0D:44:xx:xx:xx"
	}

If the name value is present then snd_names_list() will show it and
otherwise not. Telling people to add entries in two files sounds not
right to me.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click

Re: Re: Device name lists

[Clemens Ladisch]

Marcel Holtmann wrote:
> 1) What is the reason for not merging /etc/asound.names and ~/.asoundnm?

Probably the ability to remove names (otherwise we'd need some special
syntax for this).

> 2) Is another config file really needed? Why not add another parameter
> called "name" to the current config file. So that I can simply create
> this entry for my Bluetooth headphone from HP:
>
> 	pcm.hp {
> 	        type a2dp
> 	        name "HP stereo headphone"
> 	        bdaddr "00:0D:44:xx:xx:xx"
> 	}

This wouldn't work for definitions having parameters.  It would force
users to create a separate definition just so that it can be named.

Logically, these names are one abstraction level above the exising
device names.


Regards,
Clemens



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click

Re: Re: Device name lists

[Jaroslav Kysela]

On Tue, 10 May 2005, Clemens Ladisch wrote:

> Marcel Holtmann wrote:
> > 1) What is the reason for not merging /etc/asound.names and ~/.asoundnm?
> 
> Probably the ability to remove names (otherwise we'd need some special
> syntax for this).

Exactly. It's not easy to do the merging.

> > 2) Is another config file really needed? Why not add another parameter
> > called "name" to the current config file. So that I can simply create
> > this entry for my Bluetooth headphone from HP:
> >
> > 	pcm.hp {
> > 	        type a2dp
> > 	        name "HP stereo headphone"
> > 	        bdaddr "00:0D:44:xx:xx:xx"
> > 	}
> 
> This wouldn't work for definitions having parameters.  It would force
> users to create a separate definition just so that it can be named.
> 
> Logically, these names are one abstraction level above the exising
> device names.

Yes, I discovered this when I was doing the implementation preparation.
While we agreed with Takashi not to describe the parameters (it would be 
very complex), the simple list of device names must be totaly separate 
outside the plugin specification.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click