alsa-lib plugin devel

alsa-lib plugin devel

[Brad Midgley]

Hi

I've started working on an alsa-lib plugin to send audio to a bluetooth 
device (see http://bluetooth-alsa.sf.net)

I stubbed it out so I can see that it gets invoked when I address it 
directly with

	aplay -B 1000000 -D pcm.a2dp sound.wav

And I can see it is invoking the plugin code (just filled in with a 
bunch of printf's). What I'm struggling with is how to make this driver 
appear to clients that use alsa-lib. In the simplest case,

	aplay --list-devices

Does not show my device in its list! So clients that look up alsa 
devices will never see it.

my .asoundrc looks like:

	pcm.a2dpplug {
         	type plug
	        slave { pcm "a2dp" }
	}

	pcm.a2dp {
         	type a2dp
	        bdaddr "00:08:F4:30:05:BB"
	}

and I tried it with and without the first section. How do I get my 
bluetooth device to show up in a device scan?

Brad


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: alsa-lib plugin devel

[Clemens Ladisch]

Brad Midgley wrote:
> 	aplay -B 1000000 -D pcm.a2dp sound.wav
>
> What I'm struggling with is how to make this driver
> appear to clients that use alsa-lib. In the simplest case,
>
> 	aplay --list-devices
>
> Does not show my device in its list!

"aplay -l" shows only hardware devices, i.e., devices that can be
accessed with the hw plugin.

There is no simple enumeration function for plugin pcm's.


HTH
Clemens



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: alsa-lib plugin devel

[Brad Midgley]

Hi

None of the gui alsa-lib clients I've used allow for a freeform device 
name to be entered. Should we be telling linphone, xine, gnomemeeting, 
etc developers to allow a freeform device name? They currently just 
enumerate the (hw I guess) devices and make you choose from what they found.

Can I get around this problem by using esd or arts?

brad

Clemens Ladisch wrote:
> Brad Midgley wrote:
> 
>>	aplay -B 1000000 -D pcm.a2dp sound.wav
>>
>>What I'm struggling with is how to make this driver
>>appear to clients that use alsa-lib. In the simplest case,
>>
>>	aplay --list-devices
>>
>>Does not show my device in its list!
> 
> 
> "aplay -l" shows only hardware devices, i.e., devices that can be
> accessed with the hw plugin.
> 
> There is no simple enumeration function for plugin pcm's.
> 
> 
> HTH
> Clemens
> 


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: alsa-lib plugin devel

[Takashi Iwai]

At Mon, 24 Jan 2005 09:31:26 -0700,
Brad Midgley wrote:
> 
> Hi
> 
> None of the gui alsa-lib clients I've used allow for a freeform device 
> name to be entered.

Hmm, I thought many of them allow to a free text.

>  Should we be telling linphone, xine, gnomemeeting, 
> etc developers to allow a freeform device name?

Yes.

We can create a new API to list up the available PCMs.
It will help applications, I guess.

The problem is that plugins which aren't bound to drivers like btsco
are hard to detect whether they really work in advance.
Do we need a probe callback for such a plugin?


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: alsa-lib plugin devel

[Brad Midgley]

Takashi,

> We can create a new API to list up the available PCMs.
> It will help applications, I guess.
> 
> The problem is that plugins which aren't bound to drivers like btsco
> are hard to detect whether they really work in advance.
> Do we need a probe callback for such a plugin?

I suppose there are problems listing things because the plugins behave 
differently. I don't fully understand the problem.

But... it would be a big inconvenience for the user to be told to know 
the device name or go look it up in .asoundrc and/or /etc/asound.conf. 
The {linphone,xine,gnomemeeting} gui should be able to discover and list 
the plugin devices.

Brad


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: alsa-lib plugin devel

[Takashi Iwai]

At Mon, 24 Jan 2005 09:49:49 -0700,
Brad Midgley wrote:
> 
> Takashi,
> 
> > We can create a new API to list up the available PCMs.
> > It will help applications, I guess.
> > 
> > The problem is that plugins which aren't bound to drivers like btsco
> > are hard to detect whether they really work in advance.
> > Do we need a probe callback for such a plugin?
> 
> I suppose there are problems listing things because the plugins behave 
> differently. I don't fully understand the problem.
> 
> But... it would be a big inconvenience for the user to be told to know 
> the device name or go look it up in .asoundrc and/or /etc/asound.conf. 
> The {linphone,xine,gnomemeeting} gui should be able to discover and list 
> the plugin devices.

I think putting marks in the PCM defintions is the easiest way.

Another question about listing devices: shall we list up the entries
like "front", "rear", etc?

IMO, the function should list up only the basic PCMs.  I.e. the
default analog output and the SPDIF (or whatever additional outputs).


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: alsa-lib plugin devel

[Marcel Holtmann]

Hi Takashi,

> > > We can create a new API to list up the available PCMs.
> > > It will help applications, I guess.
> > > 
> > > The problem is that plugins which aren't bound to drivers like btsco
> > > are hard to detect whether they really work in advance.
> > > Do we need a probe callback for such a plugin?
> > 
> > I suppose there are problems listing things because the plugins behave 
> > differently. I don't fully understand the problem.
> > 
> > But... it would be a big inconvenience for the user to be told to know 
> > the device name or go look it up in .asoundrc and/or /etc/asound.conf. 
> > The {linphone,xine,gnomemeeting} gui should be able to discover and list 
> > the plugin devices.
> 
> I think putting marks in the PCM defintions is the easiest way.
> 
> Another question about listing devices: shall we list up the entries
> like "front", "rear", etc?
> 
> IMO, the function should list up only the basic PCMs.  I.e. the
> default analog output and the SPDIF (or whatever additional outputs).

from the Bluetooth standpoint we need only to list the input and
outputs, because there is nothing more defined. Neither for SCO or for
the A2DP devices.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: alsa-lib plugin devel

[Marcel Holtmann]

Hi Takashi,

> The problem is that plugins which aren't bound to drivers like btsco
> are hard to detect whether they really work in advance.
> Do we need a probe callback for such a plugin?

I don't think that this is needed. If people want to use a plugin to
access a Bluetooth headset or headphone they need its address and at
least put this in a configuration file. So adding something like

	pcm.aiptek {
	        type a2dp
	        bdaddr "00:0B:0D:50:12:10"
	}

to their .asoundrc to connect to the Aiptek Bluetooth Headphone should
be enough. However these devices should be present in the enumeration of
the applications.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: alsa-lib plugin devel

[Takashi Iwai]

At Mon, 24 Jan 2005 17:53:04 +0100,
Marcel Holtmann wrote:
> 
> Hi Takashi,
> 
> > The problem is that plugins which aren't bound to drivers like btsco
> > are hard to detect whether they really work in advance.
> > Do we need a probe callback for such a plugin?
> 
> I don't think that this is needed. If people want to use a plugin to
> access a Bluetooth headset or headphone they need its address and at
> least put this in a configuration file. So adding something like
> 
> 	pcm.aiptek {
> 	        type a2dp
> 	        bdaddr "00:0B:0D:50:12:10"
> 	}
> 
> to their .asoundrc to connect to the Aiptek Bluetooth Headphone should
> be enough.

Ah yes, BT SCO would require always a certain address, so it won't work
without a proper configuration.  Maybe other hardware layer will be,
too.

>  However these devices should be present in the enumeration of
> the applications.

One of the simplest solutions is to add a field to PCM definition so
that the defined PCM is marked to be listed.  Such as

	pcm.aiptek {
		type a2dp
 	        bdaddr "00:0B:0D:50:12:10"
		listed yes
 	}
		
(Well "listed" isn't a good word at all.  Please suggest a better
 one.)


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: alsa-lib plugin devel

[Marcel Holtmann]

Hi Takashi,

> > > The problem is that plugins which aren't bound to drivers like btsco
> > > are hard to detect whether they really work in advance.
> > > Do we need a probe callback for such a plugin?
> > 
> > I don't think that this is needed. If people want to use a plugin to
> > access a Bluetooth headset or headphone they need its address and at
> > least put this in a configuration file. So adding something like
> > 
> > 	pcm.aiptek {
> > 	        type a2dp
> > 	        bdaddr "00:0B:0D:50:12:10"
> > 	}
> > 
> > to their .asoundrc to connect to the Aiptek Bluetooth Headphone should
> > be enough.
> 
> Ah yes, BT SCO would require always a certain address, so it won't work
> without a proper configuration.  Maybe other hardware layer will be,
> too.
> 
> >  However these devices should be present in the enumeration of
> > the applications.
> 
> One of the simplest solutions is to add a field to PCM definition so
> that the defined PCM is marked to be listed.  Such as
> 
> 	pcm.aiptek {
> 		type a2dp
>  	        bdaddr "00:0B:0D:50:12:10"
> 		listed yes
>  	}
> 		
> (Well "listed" isn't a good word at all.  Please suggest a better
>  one.)

is this a config option that the ALSA core parses or must we do it by
ourself. However in both cases I think that the plugin itself will
decide if its devices are listed or not. In the case of a2dp the option
"type a2dp" should result in asking the plugin if its devices (or maybe
this device) are listed or not. An additional option looks for me like
over-configuration.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: alsa-lib plugin devel

[Takashi Iwai]

At Mon, 24 Jan 2005 18:23:06 +0100,
Marcel Holtmann wrote:
> 
> Hi Takashi,
> 
> > > > The problem is that plugins which aren't bound to drivers like btsco
> > > > are hard to detect whether they really work in advance.
> > > > Do we need a probe callback for such a plugin?
> > > 
> > > I don't think that this is needed. If people want to use a plugin to
> > > access a Bluetooth headset or headphone they need its address and at
> > > least put this in a configuration file. So adding something like
> > > 
> > > 	pcm.aiptek {
> > > 	        type a2dp
> > > 	        bdaddr "00:0B:0D:50:12:10"
> > > 	}
> > > 
> > > to their .asoundrc to connect to the Aiptek Bluetooth Headphone should
> > > be enough.
> > 
> > Ah yes, BT SCO would require always a certain address, so it won't work
> > without a proper configuration.  Maybe other hardware layer will be,
> > too.
> > 
> > >  However these devices should be present in the enumeration of
> > > the applications.
> > 
> > One of the simplest solutions is to add a field to PCM definition so
> > that the defined PCM is marked to be listed.  Such as
> > 
> > 	pcm.aiptek {
> > 		type a2dp
> >  	        bdaddr "00:0B:0D:50:12:10"
> > 		listed yes
> >  	}
> > 		
> > (Well "listed" isn't a good word at all.  Please suggest a better
> >  one.)
> 
> is this a config option that the ALSA core parses or must we do it by
> ourself. However in both cases I think that the plugin itself will
> decide if its devices are listed or not.

Agreed, I/O plugin can set itself as the list candidate.

>  In the case of a2dp the option
> "type a2dp" should result in asking the plugin if its devices (or maybe
> this device) are listed or not. An additional option looks for me like
> over-configuration.

Well, I think it's useful to have this as an option, too.
If you have your own favorite configuration, you can add it to the
list of supported devices.
The attribute should be off as default, of course.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: alsa-lib plugin devel

[Marcel Holtmann]

Hi Takashi,

> > > One of the simplest solutions is to add a field to PCM definition so
> > > that the defined PCM is marked to be listed.  Such as
> > > 
> > > 	pcm.aiptek {
> > > 		type a2dp
> > >  	        bdaddr "00:0B:0D:50:12:10"
> > > 		listed yes
> > >  	}
> > > 		
> > > (Well "listed" isn't a good word at all.  Please suggest a better
> > >  one.)
> > 
> > is this a config option that the ALSA core parses or must we do it by
> > ourself. However in both cases I think that the plugin itself will
> > decide if its devices are listed or not.
> 
> Agreed, I/O plugin can set itself as the list candidate.

I think this is the best way to keep the configuration simple, because
the I/O plugins always deal with real hardware.

> >  In the case of a2dp the option
> > "type a2dp" should result in asking the plugin if its devices (or maybe
> > this device) are listed or not. An additional option looks for me like
> > over-configuration.
> 
> Well, I think it's useful to have this as an option, too.
> If you have your own favorite configuration, you can add it to the
> list of supported devices.
> The attribute should be off as default, of course.

I don't need it, but if you think this useful, why not add something
like that.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: alsa-lib plugin devel

[Brad Midgley]

Takashi

> Agreed, I/O plugin can set itself as the list candidate.
> 
> 
>> In the case of a2dp the option
>>"type a2dp" should result in asking the plugin if its devices (or maybe
>>this device) are listed or not. An additional option looks for me like
>>over-configuration.
> 
> 
> Well, I think it's useful to have this as an option, too.
> If you have your own favorite configuration, you can add it to the
> list of supported devices.
> The attribute should be off as default, of course.

This sounds great. It's your project, so I shouldn't jump in and do it 
but let me know if you do want me to get in there. As long as you intend 
to make this change, it makes the plugin development worthwhile from my 
perspective. :)

One question... will the client need to change how they query for 
devices? How much latitude do you have while keeping the api stable?

Brad


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: alsa-lib plugin devel

[Takashi Iwai]

At Mon, 24 Jan 2005 13:08:25 -0700,
Brad Midgley wrote:
> 
> Takashi
> 
> > Agreed, I/O plugin can set itself as the list candidate.
> > 
> > 
> >> In the case of a2dp the option
> >>"type a2dp" should result in asking the plugin if its devices (or maybe
> >>this device) are listed or not. An additional option looks for me like
> >>over-configuration.
> > 
> > 
> > Well, I think it's useful to have this as an option, too.
> > If you have your own favorite configuration, you can add it to the
> > list of supported devices.
> > The attribute should be off as default, of course.
> 
> This sounds great. It's your project, so I shouldn't jump in and do it 
> but let me know if you do want me to get in there. As long as you intend 
> to make this change, it makes the plugin development worthwhile from my 
> perspective. :)
> 
> One question... will the client need to change how they query for 
> devices? How much latitude do you have while keeping the api stable?

It'll be an additional API function.  So, applications will need
rewrite, of course, if they use the new query function.

But I won't change the existing APIs.  This should never happen, at
least, during ALSA 1.0.x.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: alsa-lib plugin devel

[Florian Schmidt]

On Mon, 24 Jan 2005 18:09:36 +0100
Takashi Iwai <tiwai@suse.de> wrote:

> 	pcm.aiptek {
> 		type a2dp
>  	        bdaddr "00:0B:0D:50:12:10"
> 		listed yes
>  	}
> 		
> (Well "listed" isn't a good word at all.  Please suggest a better
>  one.)

My suggestion was 'register [description]':

http://sourceforge.net/mailarchive/message.php?msg_id=9849308

Flo

-- 
Palimm Palimm!
http://affenbande.org/~tapas/


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: alsa-lib plugin devel

[Jaroslav Kysela]

On Mon, 24 Jan 2005, Brad Midgley wrote:

> Hi
> 
> I've started working on an alsa-lib plugin to send audio to a bluetooth 
> device (see http://bluetooth-alsa.sf.net)
> 
> I stubbed it out so I can see that it gets invoked when I address it 
> directly with
> 
> 	aplay -B 1000000 -D pcm.a2dp sound.wav
> 
> And I can see it is invoking the plugin code (just filled in with a 
> bunch of printf's). What I'm struggling with is how to make this driver 
> appear to clients that use alsa-lib. In the simplest case,
> 
> 	aplay --list-devices

The control interface is used here (alsa-lib/src/control/).

						Jaroslav

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


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl