From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: External PCM plugin SDK Date: Thu, 10 Feb 2005 19:30:52 +0100 Message-ID: References: <1107958458.13863.43.camel@pegasus> <1107959869.13863.62.camel@pegasus> <1107970036.13863.77.camel@pegasus> <1107971323.13863.90.camel@pegasus> <1108038565.15974.20.camel@pegasus> <1108057507.15974.97.camel@pegasus> <1108058761.15974.107.camel@pegasus> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII 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: Marcel Holtmann Cc: alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org At Thu, 10 Feb 2005 19:21:18 +0100, I wrote: > > At Thu, 10 Feb 2005 19:06:01 +0100, > Marcel Holtmann wrote: > > > > Hi Takashi, > > > > > > > > > > Problem now is that XMMS closes the device and re-opens it when changing > > > > > > > > the track and even when switching to its next track. This is problematic > > > > > > > > when using Bluetooth, because I need to keep the underlaying connection > > > > > > > > alive. Any idea? > > > > > > > > > > > > > > Yeah, that's bad behavior of xmms. > > > > > > > I'll try a hack later... > > > > > > > > > > > > Another way is that I implement somekind of keep alive mechanism inside > > > > > > the plugin, but what I have seen so far is that it is directly unloaded > > > > > > when it is no longer used. So the 1:1 mapping of open/close is not a > > > > > > good thing and maybe there should be some keep alive and reset inside > > > > > > the ALSA library to help here out. > > > > > > > > > > The delayed close in the plugin is of course good to have. > > > > > My only concern is that the code would be complicated to handle > > > > > races. > > > > > > > > actually I see a lifetime race inside the plugin if I try to handle it > > > > by myself. When the close() callback is called, I must free all of my > > > > allocated resources, because the shared object will be unloaded, right? > > > > > > Yes, the close callback should clean up everything since there is no > > > distinction between close and unload, so far. > > > > if the ALSA core is not handling the XMMS behaviour for us, I really > > need something to distinguish between close and unload. > > > > What do you think about doing it like with kernel modules? Means we add > > an init and an exit entry point inside the plugin. The rest is done via > > callbacks. With this we should be able to register a PCM and also the > > mixer controls for it within the same plugin. > > That's a good idea. ... and doesn't work as it is, unfortunately :-< dlcose() is called after snd_pcm_close(). We may need to build object caches in alsa-lib. This will improve the perfomance eventually, too. Takashi ------------------------------------------------------- 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