All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Jaroslav Kysela <perex@suse.cz>
Cc: alsa-devel@lists.sourceforge.net
Subject: Re: Plugin loading and unloading
Date: Mon, 09 May 2005 10:16:23 +0200	[thread overview]
Message-ID: <1115626583.8949.124.camel@pegasus> (raw)
In-Reply-To: <Pine.LNX.4.58.0505090950410.1843@pnote.perex-int.cz>

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

  reply	other threads:[~2005-05-09  8:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-23 14:36 Plugin loading and unloading Marcel Holtmann
2005-04-30 11:35 ` Marcel Holtmann
2005-05-09  8:10 ` Jaroslav Kysela
2005-05-09  8:16   ` Marcel Holtmann [this message]
2005-05-09  8:36     ` Jaroslav Kysela
2005-05-09  9:07       ` Marcel Holtmann
2005-05-10 11:21         ` Device name lists Jaroslav Kysela
2005-05-10 15:19           ` Marcel Holtmann
2005-05-10 15:32             ` Clemens Ladisch
2005-05-10 15:57               ` Jaroslav Kysela

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1115626583.8949.124.camel@pegasus \
    --to=marcel@holtmann.org \
    --cc=alsa-devel@lists.sourceforge.net \
    --cc=perex@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.