From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: alsa-lib plugin devel Date: Mon, 24 Jan 2005 18:41:06 +0100 Message-ID: References: <41F522DE.30702@xmission.com> <1106585584.8058.61.camel@pegasus> <1106587386.8058.69.camel@pegasus> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: <1106587386.8058.69.camel@pegasus> 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: Brad Midgley , Clemens Ladisch , alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org 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