External PCM plugin SDK

External PCM plugin SDK

[Takashi Iwai]

Hi,

I now commited a patch to add the external PCM plugin SDK to
alsa-lib.  This allows you to create ALSA PCM plugin outside the
alsa-lib tree.  It's still a draft version, and currently only the I/O
plugin (e.g. for implementation of user-space driver) is provided.
The filter-type plugin SDK (e.g. for effects) and the control plugin
SDK will follow later.

No documentation yet.  Look at the code :)

Example I/O plugins are found in alsa-plugins tree.  So far, two
plugins, OSS and JACK plugins.  The former one is the plugin to
emulate ALSA API with the OSS driver.  The latter is almost identical
with the one in alsa-lib/src/pcm/ext.

I think this SDK can be used for better implementaion of BT-SCO and
FireWire.

Note that the sync of CVS tree on sourceforge is often delayed.
If you don't see it on anon tree, please wait for a while...


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

Re: External PCM plugin SDK

[Marcel Holtmann]

Hi Takashi,

> I now commited a patch to add the external PCM plugin SDK to
> alsa-lib.  This allows you to create ALSA PCM plugin outside the
> alsa-lib tree.  It's still a draft version, and currently only the I/O
> plugin (e.g. for implementation of user-space driver) is provided.
> The filter-type plugin SDK (e.g. for effects) and the control plugin
> SDK will follow later.
> 
> No documentation yet.  Look at the code :)
> 
> Example I/O plugins are found in alsa-plugins tree.  So far, two
> plugins, OSS and JACK plugins.  The former one is the plugin to
> emulate ALSA API with the OSS driver.  The latter is almost identical
> with the one in alsa-lib/src/pcm/ext.
> 
> I think this SDK can be used for better implementaion of BT-SCO and
> FireWire.

I wrote a quick and dirty prototype using SBC over RFCOMM for now. It is
working with aplay and the alsaplayer, but not with xmms or beep. Are
there any known problem with these ALSA plugins?

We also talked about making these IO plugins visible when ALSA is
listing its hardware devices. Is this possible now?

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: External PCM plugin SDK

[Takashi Iwai]

At Wed, 09 Feb 2005 15:14:18 +0100,
Marcel Holtmann wrote:
> 
> Hi Takashi,
> 
> > I now commited a patch to add the external PCM plugin SDK to
> > alsa-lib.  This allows you to create ALSA PCM plugin outside the
> > alsa-lib tree.  It's still a draft version, and currently only the I/O
> > plugin (e.g. for implementation of user-space driver) is provided.
> > The filter-type plugin SDK (e.g. for effects) and the control plugin
> > SDK will follow later.
> > 
> > No documentation yet.  Look at the code :)
> > 
> > Example I/O plugins are found in alsa-plugins tree.  So far, two
> > plugins, OSS and JACK plugins.  The former one is the plugin to
> > emulate ALSA API with the OSS driver.  The latter is almost identical
> > with the one in alsa-lib/src/pcm/ext.
> > 
> > I think this SDK can be used for better implementaion of BT-SCO and
> > FireWire.
> 
> I wrote a quick and dirty prototype using SBC over RFCOMM for now.

Wow.

>  It is
> working with aplay and the alsaplayer, but not with xmms or beep. Are
> there any known problem with these ALSA plugins?

Which xmms/bmp are you using?
I fixed ALSA plugins of xmms and bmp recently, so it might have been
fixed.  For testing, you can try the one in SUSE's rpms from STABLE.

Do you have buffer or period size constraints?

> We also talked about making these IO plugins visible when ALSA is
> listing its hardware devices. Is this possible now?

No, it's still in planning.
We'll need to define a usable API first...


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

Re: External PCM plugin SDK

[Marcel Holtmann]

Hi Takashi,

> > > I now commited a patch to add the external PCM plugin SDK to
> > > alsa-lib.  This allows you to create ALSA PCM plugin outside the
> > > alsa-lib tree.  It's still a draft version, and currently only the I/O
> > > plugin (e.g. for implementation of user-space driver) is provided.
> > > The filter-type plugin SDK (e.g. for effects) and the control plugin
> > > SDK will follow later.
> > > 
> > > No documentation yet.  Look at the code :)
> > > 
> > > Example I/O plugins are found in alsa-plugins tree.  So far, two
> > > plugins, OSS and JACK plugins.  The former one is the plugin to
> > > emulate ALSA API with the OSS driver.  The latter is almost identical
> > > with the one in alsa-lib/src/pcm/ext.
> > > 
> > > I think this SDK can be used for better implementaion of BT-SCO and
> > > FireWire.
> > 
> > I wrote a quick and dirty prototype using SBC over RFCOMM for now.
> 
> Wow.

it is putting the PCM data into the SBC encoder and then sending it to
the RFCOMM socket. This is not the standard for high quality audio over
Bluetooth, but my Aiptek headphone supports this stuff. For now this is
easier than dealing with A2DP and AVDTP.

The SCO support for the headsets is another story.

> >  It is
> > working with aplay and the alsaplayer, but not with xmms or beep. Are
> > there any known problem with these ALSA plugins?
> 
> Which xmms/bmp are you using?
> I fixed ALSA plugins of xmms and bmp recently, so it might have been
> fixed.  For testing, you can try the one in SUSE's rpms from STABLE.

The XMMS is version 1.2.10 and BMP is version 0.9.7. In what versions
are the ALSA plugins fixed. I will build it from source.

> Do you have buffer or period size constraints?

Oh yes, that is the point where I am not sure what I am doing. The SBC
is a codec like MP3 and actually I have no idea what are the best values
here. These are software soundcards.

> > We also talked about making these IO plugins visible when ALSA is
> > listing its hardware devices. Is this possible now?
> 
> No, it's still in planning.
> We'll need to define a usable API first...

What about a flags variable in snd_pcm_ioplug for activating it. This is
generic and for me this is enough, because both Bluetooth IO plugins are
virtual soundcards and they should always be listed. Or maybe list IO
plugins in general.

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: External PCM plugin SDK

[Takashi Iwai]

At Wed, 09 Feb 2005 15:37:49 +0100,
Marcel Holtmann wrote:
> 
> Hi Takashi,
> 
> > > > I now commited a patch to add the external PCM plugin SDK to
> > > > alsa-lib.  This allows you to create ALSA PCM plugin outside the
> > > > alsa-lib tree.  It's still a draft version, and currently only the I/O
> > > > plugin (e.g. for implementation of user-space driver) is provided.
> > > > The filter-type plugin SDK (e.g. for effects) and the control plugin
> > > > SDK will follow later.
> > > > 
> > > > No documentation yet.  Look at the code :)
> > > > 
> > > > Example I/O plugins are found in alsa-plugins tree.  So far, two
> > > > plugins, OSS and JACK plugins.  The former one is the plugin to
> > > > emulate ALSA API with the OSS driver.  The latter is almost identical
> > > > with the one in alsa-lib/src/pcm/ext.
> > > > 
> > > > I think this SDK can be used for better implementaion of BT-SCO and
> > > > FireWire.
> > > 
> > > I wrote a quick and dirty prototype using SBC over RFCOMM for now.
> > 
> > Wow.
> 
> it is putting the PCM data into the SBC encoder and then sending it to
> the RFCOMM socket. This is not the standard for high quality audio over
> Bluetooth, but my Aiptek headphone supports this stuff. For now this is
> easier than dealing with A2DP and AVDTP.
> 
> The SCO support for the headsets is another story.

... and we'll need control plugin for mixers, too.

> > >  It is
> > > working with aplay and the alsaplayer, but not with xmms or beep. Are
> > > there any known problem with these ALSA plugins?
> > 
> > Which xmms/bmp are you using?
> > I fixed ALSA plugins of xmms and bmp recently, so it might have been
> > fixed.  For testing, you can try the one in SUSE's rpms from STABLE.
> 
> The XMMS is version 1.2.10 and BMP is version 0.9.7. In what versions
> are the ALSA plugins fixed. I will build it from source.

The patch isn't in the released version.  IIRC, they were applied to
CVS, though.

> > Do you have buffer or period size constraints?
> 
> Oh yes, that is the point where I am not sure what I am doing. The SBC
> is a codec like MP3 and actually I have no idea what are the best values
> here. These are software soundcards.

You don't have to set them if the hardware has no restriction.
Usually, the period size defines the interrupt period.  In the case of
user-space driver, it corresponds to the expected poll period, etc.

> > > We also talked about making these IO plugins visible when ALSA is
> > > listing its hardware devices. Is this possible now?
> > 
> > No, it's still in planning.
> > We'll need to define a usable API first...
> 
> What about a flags variable in snd_pcm_ioplug for activating it. This is
> generic and for me this is enough, because both Bluetooth IO plugins are
> virtual soundcards and they should always be listed. Or maybe list IO
> plugins in general.

This sounds good.  I'll add like the following:

Index: alsa-lib/include/pcm_ioplug.h
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-lib/include/pcm_ioplug.h,v
retrieving revision 1.3
diff -u -r1.3 pcm_ioplug.h
--- alsa-lib/include/pcm_ioplug.h	8 Feb 2005 20:48:56 -0000	1.3
+++ alsa-lib/include/pcm_ioplug.h	9 Feb 2005 15:14:06 -0000
@@ -37,10 +37,13 @@
 typedef struct snd_pcm_ioplug snd_pcm_ioplug_t;
 typedef struct snd_pcm_ioplug_callback snd_pcm_ioplug_callback_t;
 
+#define SND_PCM_IOPLUG_FLAG_LISTED	(1<<0)
+
 /* exported pcm data */
 struct snd_pcm_ioplug {
 	/* must be filled before calling snd_pcm_ioplug_create() */
 	const char *name;
+	unsigned int flags;	/* SND_PCM_IOPLUG_FLAG_XXX */
 	int poll_fd;
 	unsigned int poll_events;
 	unsigned int mmap_rw;		/* pseudo mmap */



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

Re: External PCM plugin SDK

[Marcel Holtmann]

Hi Takashi,

> > it is putting the PCM data into the SBC encoder and then sending it to
> > the RFCOMM socket. This is not the standard for high quality audio over
> > Bluetooth, but my Aiptek headphone supports this stuff. For now this is
> > easier than dealing with A2DP and AVDTP.
> > 
> > The SCO support for the headsets is another story.
> 
> ... and we'll need control plugin for mixers, too.

and I need full duplex IO and volume control inside the same plugin for
the headset/handsfree support.

> > The XMMS is version 1.2.10 and BMP is version 0.9.7. In what versions
> > are the ALSA plugins fixed. I will build it from source.
> 
> The patch isn't in the released version.  IIRC, they were applied to
> CVS, though.

I checked the latest XMMS CVS and even it segfaults or I get an error:

xmms: pcm_params.c:2294: sndrv_pcm_hw_params: Assertion `err >= 0' failed.

Looks like a problem on my side.

> > > Do you have buffer or period size constraints?
> > 
> > Oh yes, that is the point where I am not sure what I am doing. The SBC
> > is a codec like MP3 and actually I have no idea what are the best values
> > here. These are software soundcards.
> 
> You don't have to set them if the hardware has no restriction.
> Usually, the period size defines the interrupt period.  In the case of
> user-space driver, it corresponds to the expected poll period, etc.

I can skip IOPLUG_HW_PERIOD_BYTES and IOPLUG_HW_PERIODS, but I must set
IOPLUG_HW_BUFFER_BYTES, because otherwise it segfaults even with aplay.

> > > > We also talked about making these IO plugins visible when ALSA is
> > > > listing its hardware devices. Is this possible now?
> > > 
> > > No, it's still in planning.
> > > We'll need to define a usable API first...
> > 
> > What about a flags variable in snd_pcm_ioplug for activating it. This is
> > generic and for me this is enough, because both Bluetooth IO plugins are
> > virtual soundcards and they should always be listed. Or maybe list IO
> > plugins in general.
> 
> This sounds good.  I'll add like the following:

Let's take an unsigned long to handle more than 32 flags ;)

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: External PCM plugin SDK

[Takashi Iwai]

At Wed, 09 Feb 2005 18:27:16 +0100,
Marcel Holtmann wrote:
> 
> Hi Takashi,
> 
> > > it is putting the PCM data into the SBC encoder and then sending it to
> > > the RFCOMM socket. This is not the standard for high quality audio over
> > > Bluetooth, but my Aiptek headphone supports this stuff. For now this is
> > > easier than dealing with A2DP and AVDTP.
> > > 
> > > The SCO support for the headsets is another story.
> > 
> > ... and we'll need control plugin for mixers, too.
> 
> and I need full duplex IO and volume control inside the same plugin for
> the headset/handsfree support.

Hmm, the share of volume control stuff between PCM and control plugins
might be a bit tough.

> > > The XMMS is version 1.2.10 and BMP is version 0.9.7. In what versions
> > > are the ALSA plugins fixed. I will build it from source.
> > 
> > The patch isn't in the released version.  IIRC, they were applied to
> > CVS, though.
> 
> I checked the latest XMMS CVS and even it segfaults or I get an error:
> 
> xmms: pcm_params.c:2294: sndrv_pcm_hw_params: Assertion `err >= 0' failed.
> 
> Looks like a problem on my side.
> 
> > > > Do you have buffer or period size constraints?
> > > 
> > > Oh yes, that is the point where I am not sure what I am doing. The SBC
> > > is a codec like MP3 and actually I have no idea what are the best values
> > > here. These are software soundcards.
> > 
> > You don't have to set them if the hardware has no restriction.
> > Usually, the period size defines the interrupt period.  In the case of
> > user-space driver, it corresponds to the expected poll period, etc.
> 
> I can skip IOPLUG_HW_PERIOD_BYTES and IOPLUG_HW_PERIODS, but I must set
> IOPLUG_HW_BUFFER_BYTES, because otherwise it segfaults even with aplay.

OK, then use snd_pcm_ioplug_set_param_minmax() with some sane values.

> > > > > We also talked about making these IO plugins visible when ALSA is
> > > > > listing its hardware devices. Is this possible now?
> > > > 
> > > > No, it's still in planning.
> > > > We'll need to define a usable API first...
> > > 
> > > What about a flags variable in snd_pcm_ioplug for activating it. This is
> > > generic and for me this is enough, because both Bluetooth IO plugins are
> > > virtual soundcards and they should always be listed. Or maybe list IO
> > > plugins in general.
> > 
> > This sounds good.  I'll add like the following:
> 
> Let's take an unsigned long to handle more than 32 flags ;)

Well, I'd like to keep 32bit.

Nowadays no one knows whether the exported struct is shared between
32bit and 64bit environment.  Once if we have to implement a 32bit
wrapper, the difference of long is simply a pain.


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

Re: External PCM plugin SDK

[Marcel Holtmann]

Hi Takashi,

> > and I need full duplex IO and volume control inside the same plugin for
> > the headset/handsfree support.
> 
> Hmm, the share of volume control stuff between PCM and control plugins
> might be a bit tough.

the problem is that the headsets can report back volume changes. We will
see this for the high quality headphones also some day, because the
audio and video remote stuff for Bluetooth is already specified.

I will start without reacting to the volume control. We will see how
this works out.

> > > You don't have to set them if the hardware has no restriction.
> > > Usually, the period size defines the interrupt period.  In the case of
> > > user-space driver, it corresponds to the expected poll period, etc.
> > 
> > I can skip IOPLUG_HW_PERIOD_BYTES and IOPLUG_HW_PERIODS, but I must set
> > IOPLUG_HW_BUFFER_BYTES, because otherwise it segfaults even with aplay.
> 
> OK, then use snd_pcm_ioplug_set_param_minmax() with some sane values.

Leaving IOPLUG_HW_BUFFERS_BYTES out and only setting the period stuff
makes it working with the XMMS from CVS.

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?

> > Let's take an unsigned long to handle more than 32 flags ;)
> 
> Well, I'd like to keep 32bit.
> 
> Nowadays no one knows whether the exported struct is shared between
> 32bit and 64bit environment.  Once if we have to implement a 32bit
> wrapper, the difference of long is simply a pain.

Fine with me.

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: External PCM plugin SDK

[Takashi Iwai]

At Wed, 09 Feb 2005 18:48:43 +0100,
Marcel Holtmann wrote:
> 
> Hi Takashi,
> 
> > > and I need full duplex IO and volume control inside the same plugin for
> > > the headset/handsfree support.
> > 
> > Hmm, the share of volume control stuff between PCM and control plugins
> > might be a bit tough.
> 
> the problem is that the headsets can report back volume changes. We will
> see this for the high quality headphones also some day, because the
> audio and video remote stuff for Bluetooth is already specified.
> 
> I will start without reacting to the volume control. We will see how
> this works out.
 
If so, running a daemon might be possibly easier than doing concurrent
access?

> > > > You don't have to set them if the hardware has no restriction.
> > > > Usually, the period size defines the interrupt period.  In the case of
> > > > user-space driver, it corresponds to the expected poll period, etc.
> > > 
> > > I can skip IOPLUG_HW_PERIOD_BYTES and IOPLUG_HW_PERIODS, but I must set
> > > IOPLUG_HW_BUFFER_BYTES, because otherwise it segfaults even with aplay.
> > 
> > OK, then use snd_pcm_ioplug_set_param_minmax() with some sane values.
> 
> Leaving IOPLUG_HW_BUFFERS_BYTES out and only setting the period stuff
> makes it working with the XMMS from CVS.

Good to hear :)

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


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

Re: External PCM plugin SDK

[Marcel Holtmann]

Hi Takashi,

> > > > and I need full duplex IO and volume control inside the same plugin for
> > > > the headset/handsfree support.
> > > 
> > > Hmm, the share of volume control stuff between PCM and control plugins
> > > might be a bit tough.
> > 
> > the problem is that the headsets can report back volume changes. We will
> > see this for the high quality headphones also some day, because the
> > audio and video remote stuff for Bluetooth is already specified.
> > 
> > I will start without reacting to the volume control. We will see how
> > this works out.
>  
> If so, running a daemon might be possibly easier than doing concurrent
> access?

actually I see the headsets and also the headphones as virtual software
soundcards and so a plugin for them should deal with the PCM stream and
also the mixer settings. My idea is to make it transparent for the end
user. Once they configured their device in .asoundrc they never have to
worry about it again.

Maybe we can have a second entry point in the shared object. One is for
the PCM and the other one for the mixer settings.

> > Leaving IOPLUG_HW_BUFFERS_BYTES out and only setting the period stuff
> > makes it working with the XMMS from CVS.
> 
> Good to hear :)

I checked BMP from CVS now and this is also working.

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

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: External PCM plugin SDK

[Takashi Iwai]

At Thu, 10 Feb 2005 13:29:25 +0100,
Marcel Holtmann wrote:
> 
> > > 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.


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

Re: External PCM plugin SDK

[Takashi Iwai]

At Thu, 10 Feb 2005 18:45:07 +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.


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

Re: External PCM plugin SDK

[Marcel Holtmann]

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.

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: External PCM plugin SDK

[Takashi Iwai]

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.


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

Re: External PCM plugin SDK

[Takashi Iwai]

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

Re: External PCM plugin SDK

[Marcel Holtmann]

Hi Takashi,

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

questions is what will break if you change it. The only official plugin
is the Jack plugin, right? So be bad and change this stuff and then fix
the plugins.

Maybe a delayed unload (idle timeout) and adding reference counting to a
plugin will help here.

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: External PCM plugin SDK

[Takashi Iwai]

At Thu, 10 Feb 2005 20:04:30 +0100,
Marcel Holtmann wrote:
> 
> Hi Takashi,
> 
> > > > > > > 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.
> 
> questions is what will break if you change it. The only official plugin
> is the Jack plugin, right? So be bad and change this stuff and then fix
> the plugins.

The compatibility will be kept, I think.  Only the plugins with a
keep-alive flag are excluded from dlclose, and the objects are reused
at the next open.


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

Re: External PCM plugin SDK

[Marcel Holtmann]

Hi Takashi,

> > > ... 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.
> > 
> > questions is what will break if you change it. The only official plugin
> > is the Jack plugin, right? So be bad and change this stuff and then fix
> > the plugins.
> 
> The compatibility will be kept, I think.  Only the plugins with a
> keep-alive flag are excluded from dlclose, and the objects are reused
> at the next open.

but I think we still should implement something like init() and exit()
of the objects. Otherwise it would not be possible to handle this in a
correct way and we will get memory leaks and unclosed descriptors.

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: External PCM plugin SDK

[Takashi Iwai]

At Fri, 11 Feb 2005 13:15:19 +0100,
Marcel Holtmann wrote:
> 
> Hi Takashi,
> 
> > > > ... 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.
> > > 
> > > questions is what will break if you change it. The only official plugin
> > > is the Jack plugin, right? So be bad and change this stuff and then fix
> > > the plugins.
> > 
> > The compatibility will be kept, I think.  Only the plugins with a
> > keep-alive flag are excluded from dlclose, and the objects are reused
> > at the next open.
> 
> but I think we still should implement something like init() and exit()
> of the objects. Otherwise it would not be possible to handle this in a
> correct way and we will get memory leaks and unclosed descriptors.

We can add the clean up of cached plugin objects (i.e. calling
dlclose) in the existing snd_config_update_free_global().  This
function is supposed to be used for clean up of config tree cache.

Each plugin with the keep-alive flag can have functions with
__attribute__((constructor)) and __attribute__((destructor)) for the
purpose above.


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

Re: External PCM plugin SDK

[Takashi Iwai]

[-- Attachment #1: Type: text/plain, Size: 1729 bytes --]

At Fri, 11 Feb 2005 14:28:34 +0100,
I wrote:
> 
> At Fri, 11 Feb 2005 13:15:19 +0100,
> Marcel Holtmann wrote:
> > 
> > Hi Takashi,
> > 
> > > > > ... 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.
> > > > 
> > > > questions is what will break if you change it. The only official plugin
> > > > is the Jack plugin, right? So be bad and change this stuff and then fix
> > > > the plugins.
> > > 
> > > The compatibility will be kept, I think.  Only the plugins with a
> > > keep-alive flag are excluded from dlclose, and the objects are reused
> > > at the next open.
> > 
> > but I think we still should implement something like init() and exit()
> > of the objects. Otherwise it would not be possible to handle this in a
> > correct way and we will get memory leaks and unclosed descriptors.
> 
> We can add the clean up of cached plugin objects (i.e. calling
> dlclose) in the existing snd_config_update_free_global().  This
> function is supposed to be used for clean up of config tree cache.
> 
> Each plugin with the keep-alive flag can have functions with
> __attribute__((constructor)) and __attribute__((destructor)) for the
> purpose above.

The below is a test patch to add the dlobj cache.

It adds a new mode flag to pcm open mode, SND_PCM_KEEP_ALIVE.
In xmms, change the call of snd_pcm_open() like:

	snd_pcm_open(...., SND_PCM_NONBLOCK | SND_PCM_KEEP_ALIVE);

and the dl object will remain alive until
snd_config_update_free_global() is called explicitly.

If the plugin needs always keep-alive, a bit more change is needed.


Takashi

[-- Attachment #2: Type: text/plain, Size: 5552 bytes --]

Index: alsa-lib/include/local.h
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-lib/include/local.h,v
retrieving revision 1.37
diff -u -r1.37 local.h
--- alsa-lib/include/local.h	11 Feb 2005 16:20:31 -0000	1.37
+++ alsa-lib/include/local.h	11 Feb 2005 16:58:50 -0000
@@ -232,4 +232,9 @@
 #define snd_open_device(filename, fmode) open(filename, fmode);
 #endif
 
+/* dlobj cache */
+void *snd_dlobj_cache_lookup(const char *name);
+int snd_dlobj_cache_add(const char *name, void *dlobj, void *open_func);
+void snd_dlobj_cache_cleanup(void);
+
 #endif
Index: alsa-lib/include/pcm.h
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-lib/include/pcm.h,v
retrieving revision 1.102
diff -u -r1.102 pcm.h
--- alsa-lib/include/pcm.h	7 Feb 2005 20:53:06 -0000	1.102
+++ alsa-lib/include/pcm.h	11 Feb 2005 17:12:50 -0000
@@ -295,6 +295,8 @@
 #define SND_PCM_NONBLOCK		0x0001
 /** Async notification (flag for open mode) \hideinitializer */
 #define SND_PCM_ASYNC			0x0002
+/** Keep the dl object alive after close */
+#define SND_PCM_KEEP_ALIVE		0x0004
 
 /** PCM handle */
 typedef struct _snd_pcm snd_pcm_t;
Index: alsa-lib/include/pcm_ioplug.h
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-lib/include/pcm_ioplug.h,v
retrieving revision 1.3
diff -u -r1.3 pcm_ioplug.h
--- alsa-lib/include/pcm_ioplug.h	8 Feb 2005 20:48:56 -0000	1.3
+++ alsa-lib/include/pcm_ioplug.h	11 Feb 2005 17:14:59 -0000
@@ -37,10 +37,13 @@
 typedef struct snd_pcm_ioplug snd_pcm_ioplug_t;
 typedef struct snd_pcm_ioplug_callback snd_pcm_ioplug_callback_t;
 
+#define SND_PCM_IOPLUG_FLAG_LISTED	(1<<0)
+
 /* exported pcm data */
 struct snd_pcm_ioplug {
 	/* must be filled before calling snd_pcm_ioplug_create() */
 	const char *name;
+	unsigned int flags;	/* SND_PCM_IOPLUG_FLAG_XXX */
 	int poll_fd;
 	unsigned int poll_events;
 	unsigned int mmap_rw;		/* pseudo mmap */
Index: alsa-lib/src/conf.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-lib/src/conf.c,v
retrieving revision 1.58
diff -u -r1.58 conf.c
--- alsa-lib/src/conf.c	9 Feb 2005 16:57:45 -0000	1.58
+++ alsa-lib/src/conf.c	11 Feb 2005 17:00:06 -0000
@@ -3105,6 +3105,10 @@
 		snd_config_update_free(snd_config_global_update);
 	snd_config_global_update = NULL;
 	pthread_mutex_unlock(&snd_config_update_mutex);
+
+	/* FIXME: better to place this in another place... */
+	snd_dlobj_cache_cleanup();
+
 	return 0;
 }
 
Index: alsa-lib/src/dlmisc.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-lib/src/dlmisc.c,v
retrieving revision 1.8
diff -u -r1.8 dlmisc.c
--- alsa-lib/src/dlmisc.c	9 Dec 2002 10:58:48 -0000	1.8
+++ alsa-lib/src/dlmisc.c	11 Feb 2005 17:19:10 -0000
@@ -29,6 +29,7 @@
 
 #define _GNU_SOURCE
 #include <dlfcn.h>
+#include "list.h"
 #include "local.h"
 
 #ifndef DOC_HIDDEN
@@ -143,3 +144,70 @@
 		return NULL;
 	return dlsym(handle, name);
 }
+
+/*
+ * dlobj cache
+ *
+ * FIXME: add reference counter and proper locking
+ */
+
+struct dlobj_cache {
+	const char *name;
+	void *obj;
+	void *func;
+	struct list_head list;
+};
+
+static LIST_HEAD(pcm_dlobj_list);
+
+void *snd_dlobj_cache_lookup(const char *name)
+{
+	struct list_head *p;
+	struct dlobj_cache *c;
+
+	list_for_each(p, &pcm_dlobj_list) {
+		c = list_entry(p, struct dlobj_cache, list);
+		if (strcmp(c->name, name) == 0)
+			return c->func;
+	}
+	return NULL;
+}
+
+int snd_dlobj_cache_add(const char *name, void *dlobj, void *open_func)
+{
+	struct list_head *p;
+	struct dlobj_cache *c;
+
+	list_for_each(p, &pcm_dlobj_list) {
+		c = list_entry(p, struct dlobj_cache, list);
+		if (strcmp(c->name, name) == 0)
+			return 0; /* already exists */
+	}
+	c = malloc(sizeof(*c));
+	if (! c)
+		return -ENOMEM;
+	c->name = strdup(name);
+	if (! c->name) {
+		free(c);
+		return -ENOMEM;
+	}
+	c->obj = dlobj;
+	c->func = open_func;
+	list_add_tail(&c->list, &pcm_dlobj_list);
+	return 0;
+}
+
+void snd_dlobj_cache_cleanup(void)
+{
+	struct list_head *p;
+	struct dlobj_cache *c;
+
+	while (! list_empty(&pcm_dlobj_list)) {
+		p = pcm_dlobj_list.next;
+		c = list_entry(p, struct dlobj_cache, list);
+		list_del(p);
+		snd_dlclose(c->obj);
+		free(c->name);
+		free(c);
+	}
+}
Index: alsa-lib/src/pcm/pcm.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-lib/src/pcm/pcm.c,v
retrieving revision 1.168
diff -u -r1.168 pcm.c
--- alsa-lib/src/pcm/pcm.c	21 Jan 2005 19:27:44 -0000	1.168
+++ alsa-lib/src/pcm/pcm.c	11 Feb 2005 17:20:36 -0000
@@ -2019,6 +2019,11 @@
 #ifndef PIC
 	snd_pcm_open_symbols();	/* this call is for static linking only */
 #endif
+	open_func = snd_dlobj_cache_lookup(open_name);
+	if (open_func) {
+		err = 0;
+		goto _err;
+	}
 	h = snd_dlopen(lib, RTLD_NOW);
 	if (h)
 		open_func = snd_dlsym(h, open_name, SND_DLSYM_VERSION(SND_PCM_DLSYM_VERSION));
@@ -2032,17 +2037,22 @@
 		err = -ENXIO;
 	}
        _err:
-	if (type_conf)
-		snd_config_delete(type_conf);
 	if (err >= 0) {
 		err = open_func(pcmp, name, pcm_root, pcm_conf, stream, mode);
 		if (err >= 0) {
+			if (h && (mode & SND_PCM_KEEP_ALIVE)) {
+				snd_dlobj_cache_add(open_name, h, open_func);
+				h = NULL;
+			}
 			(*pcmp)->dl_handle = h;
 			err = 0;
 		} else {
-			snd_dlclose(h);
+			if (h)
+				snd_dlclose(h);
 		}
 	}
+	if (type_conf)
+		snd_config_delete(type_conf);
 	if (buf)
 		free(buf);
 	if (buf1)

Re: External PCM plugin SDK

[Marcel Holtmann]

Hi Takashi,

> > > but I think we still should implement something like init() and exit()
> > > of the objects. Otherwise it would not be possible to handle this in a
> > > correct way and we will get memory leaks and unclosed descriptors.
> > 
> > We can add the clean up of cached plugin objects (i.e. calling
> > dlclose) in the existing snd_config_update_free_global().  This
> > function is supposed to be used for clean up of config tree cache.
> > 
> > Each plugin with the keep-alive flag can have functions with
> > __attribute__((constructor)) and __attribute__((destructor)) for the
> > purpose above.
> 
> The below is a test patch to add the dlobj cache.
> 
> It adds a new mode flag to pcm open mode, SND_PCM_KEEP_ALIVE.
> In xmms, change the call of snd_pcm_open() like:
> 
> 	snd_pcm_open(...., SND_PCM_NONBLOCK | SND_PCM_KEEP_ALIVE);
> 
> and the dl object will remain alive until
> snd_config_update_free_global() is called explicitly.
> 
> If the plugin needs always keep-alive, a bit more change is needed.

I personal think that the object caching should be transparent for the
applications, but I don't have the insides into the ALSA library. If it
is too hard then this might be a good solution.

However I won't have enough time to test this in detail for the next two
weeks, but the pcm_a2dp plugin is committed to the BlueZ CVS and maybe
some others want to give it a try.

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: External PCM plugin SDK

[Takashi Iwai]

At Sat, 12 Feb 2005 03:18:27 +0100,
Marcel Holtmann wrote:
> 
> Hi Takashi,
> 
> > > > but I think we still should implement something like init() and exit()
> > > > of the objects. Otherwise it would not be possible to handle this in a
> > > > correct way and we will get memory leaks and unclosed descriptors.
> > > 
> > > We can add the clean up of cached plugin objects (i.e. calling
> > > dlclose) in the existing snd_config_update_free_global().  This
> > > function is supposed to be used for clean up of config tree cache.
> > > 
> > > Each plugin with the keep-alive flag can have functions with
> > > __attribute__((constructor)) and __attribute__((destructor)) for the
> > > purpose above.
> > 
> > The below is a test patch to add the dlobj cache.
> > 
> > It adds a new mode flag to pcm open mode, SND_PCM_KEEP_ALIVE.
> > In xmms, change the call of snd_pcm_open() like:
> > 
> > 	snd_pcm_open(...., SND_PCM_NONBLOCK | SND_PCM_KEEP_ALIVE);
> > 
> > and the dl object will remain alive until
> > snd_config_update_free_global() is called explicitly.
> > 
> > If the plugin needs always keep-alive, a bit more change is needed.
> 
> I personal think that the object caching should be transparent for the
> applications, but I don't have the insides into the ALSA library. If it
> is too hard then this might be a good solution.

I introduced the additional flag just for compatibility.
But, maybe I was too nervous about that.  Basically there is no big
problem to use dl-object cache for all cases.

OK, now the CVS version keeps the dl-objects.


> However I won't have enough time to test this in detail for the next two
> weeks, but the pcm_a2dp plugin is committed to the BlueZ CVS and maybe
> some others want to give it a try.

Has anyone tried?  Any feedback is welcome.


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

Re: External PCM plugin SDK

[Thierry Vignaud]

Takashi Iwai <tiwai@suse.de> writes:

> > > > It is working with aplay and the alsaplayer, but not with xmms
> > > > or beep. Are there any known problem with these ALSA plugins?
> > > 
> > > Which xmms/bmp are you using?
> > > I fixed ALSA plugins of xmms and bmp recently, so it might have
> > > been fixed.  For testing, you can try the one in SUSE's rpms
> > > from STABLE.
> > 
> > The XMMS is version 1.2.10 and BMP is version 0.9.7. In what
> > versions are the ALSA plugins fixed. I will build it from source.
> 
> The patch isn't in the released version.  IIRC, they were applied to
> CVS, though.

it's in CVS for bmp for sure, but i don't think so for xmms.



-------------------------------------------------------
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: External PCM plugin SDK

[Takashi Iwai]

At Wed, 09 Feb 2005 18:38:32 +0100,
Thierry Vignaud wrote:
> 
> Takashi Iwai <tiwai@suse.de> writes:
> 
> > > > > It is working with aplay and the alsaplayer, but not with xmms
> > > > > or beep. Are there any known problem with these ALSA plugins?
> > > > 
> > > > Which xmms/bmp are you using?
> > > > I fixed ALSA plugins of xmms and bmp recently, so it might have
> > > > been fixed.  For testing, you can try the one in SUSE's rpms
> > > > from STABLE.
> > > 
> > > The XMMS is version 1.2.10 and BMP is version 0.9.7. In what
> > > versions are the ALSA plugins fixed. I will build it from source.
> > 
> > The patch isn't in the released version.  IIRC, they were applied to
> > CVS, though.
> 
> it's in CVS for bmp for sure, but i don't think so for xmms.

Havard wrote me that he took the patch, but I'm not sure whether it
really went to CVS.


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

Re: External PCM plugin SDK

[Jaroslav Kysela]

On Wed, 9 Feb 2005, Takashi Iwai wrote:

> > We also talked about making these IO plugins visible when ALSA is
> > listing its hardware devices. Is this possible now?
> 
> No, it's still in planning.
> We'll need to define a usable API first...

Yes, I'll try to prepare something. The general question is, if we should
describe variable parameters (like card number, device number etc. with 
this API) or if we put only (probably very long list) of available strings 
(device specifications) to applications.

Both ways have own problems (parsing of parameter description) and
the second case might cause that the list will be completely unuseable for
GUI apps.

						Jaroslav

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


-------------------------------------------------------
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: External PCM plugin SDK

[Takashi Iwai]

At Wed, 9 Feb 2005 16:25:57 +0100 (CET),
Jaroslav wrote:
> 
> On Wed, 9 Feb 2005, Takashi Iwai wrote:
> 
> > > We also talked about making these IO plugins visible when ALSA is
> > > listing its hardware devices. Is this possible now?
> > 
> > No, it's still in planning.
> > We'll need to define a usable API first...
> 
> Yes, I'll try to prepare something. The general question is, if we should
> describe variable parameters (like card number, device number etc. with 
> this API) or if we put only (probably very long list) of available strings 
> (device specifications) to applications.
> 
> Both ways have own problems (parsing of parameter description) and
> the second case might cause that the list will be completely unuseable for
> GUI apps.

I prefer a single list.  Suppose that at most one or two devices per
card are provided as default, the total size wouldn't be so big.

In addition to the API to return the list, we can create an API
function to return the description of the given PCM (or whatever).
For hw pcm, longname can be used.  For external I/O plugin, a new
description field can be added.  For user-defined things, it parses
the definition and extracts the "comment" field, for example.


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

Re: External PCM plugin SDK

[Thierry Vignaud]

Marcel Holtmann <marcel@holtmann.org> writes:

> > I think this SDK can be used for better implementaion of BT-SCO
> > and FireWire.
> 
> I wrote a quick and dirty prototype using SBC over RFCOMM for
> now. It is working with aplay and the alsaplayer, but not with xmms
> or beep. Are there any known problem with these ALSA plugins?

will you consider releasing your code for testing?



-------------------------------------------------------
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: External PCM plugin SDK

[Marcel Holtmann]

Hi Thierry,

> > > I think this SDK can be used for better implementaion of BT-SCO
> > > and FireWire.
> > 
> > I wrote a quick and dirty prototype using SBC over RFCOMM for
> > now. It is working with aplay and the alsaplayer, but not with xmms
> > or beep. Are there any known problem with these ALSA plugins?
> 
> will you consider releasing your code for testing?

it will go into the BlueZ CVS repository soon, but currently the code is
not even 24 hours old ;)

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: External PCM plugin SDK

[Alexander E. Patrakov]

Takashi Iwai wrote:

> Example I/O plugins are found in alsa-plugins tree.  So far, two
> plugins, OSS and JACK plugins.  The former one is the plugin to
> emulate ALSA API with the OSS driver.  The latter is almost identical
> with the one in alsa-lib/src/pcm/ext.

Does the existence of the OSS plugin mean that dmix now exists e.g. for
FreeBSD?

-- 
Alexander E. Patrakov



-------------------------------------------------------
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: Re: External PCM plugin SDK

[Takashi Iwai]

At Wed, 09 Feb 2005 20:28:09 +0500,
Alexander E. Patrakov wrote:
> 
> Takashi Iwai wrote:
> 
> > Example I/O plugins are found in alsa-plugins tree.  So far, two
> > plugins, OSS and JACK plugins.  The former one is the plugin to
> > emulate ALSA API with the OSS driver.  The latter is almost identical
> > with the one in alsa-lib/src/pcm/ext.
> 
> Does the existence of the OSS plugin mean that dmix now exists e.g. for
> FreeBSD?

No, it doesn't work since the required features are missing in OSS.


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

Re: External PCM plugin SDK

[Thierry Vignaud]

Takashi Iwai <tiwai@suse.de> writes:

> Example I/O plugins are found in alsa-plugins tree.  So far, two
> plugins, OSS and JACK plugins.  The former one is the plugin to
> emulate ALSA API with the OSS driver.  The latter is almost
> identical with the one in alsa-lib/src/pcm/ext.

is dmix supported with the OSS plugin?



-------------------------------------------------------
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: Re: External PCM plugin SDK

[Peter Zubaj]

Looks like your oss plugin saved lot of 4Front time. :-)

Peter Zubaj



____________________________________
>>> POZOR ZMENA - KONCERT PRESUNUTY NA 28.2.2005
RAMMSTEIN, 28.02.2005 o 20,00, Bratislava Incheba, 
Info: 0904 666 363, http://www.xl.sk 



-------------------------------------------------------
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_ide95&alloc_id\x14396&op=click

Re: Re: External PCM plugin SDK

[Takashi Iwai]

At Wed, 9 Feb 2005 16:35:46 +0100,
Peter Zubaj wrote:
> 
> Looks like your oss plugin saved lot of 4Front time. :-)

Well, don't expect that it works flawlessly :)
It's just a proof of concept how crazy you can set up a system.
For example, you can do like the following with these plugins:

OSS app -> aoss wrapper -> ALSA JACK plugin - > JACK client ->
  JACK server -> ALSA OSS plugin -> OSS kernel emulation ->
  ALSA kernel driver


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