Re: alsa-lib plugin devel

[Marcel Holtmann <marcel@holtmann.org>]

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