CVS audio-api.txt : 1st question

Hi Bluez developer,

I'm trying to move forward on the design of the Bluez audio API. I'm gonna suggest some new methods and signals to handle HFP and A2DP, however at first i feel the need to understand the following methods and signals:

Methods:
--------
void Play()
void Stop()
uint16 GetSpeakerGain()
uint16 GetMicrophoneGain()
void SetSpeakerGain(uint16 gain)
void SetMicrophoneGain(uint16 gain)

Signals:
------------

void SpeakerGainChanged(uint16 gain)
void MicrophoneGainChanged(uint16 gain)

Here is the question : aren't those actions and events not supposed to be handled by the various ALSA plugins,
that would communicate using a dedicated unix socket ?

In fact i'm afraid of the following issues if those methods/signals are available:
* An application could use snd_pcm_start to start playing, and another
one could shut down the stream using
Stop() : the result would certainly be an unexpectedly broken stream.
* Application developpers could be rather confused (Which one of Play()
or snd_pcm_start should i use? Or maybe i should use both? In this case which one am i supposed to call first ?)
* If the ALSA plugin is supposed to call those method by itself, this
would mean bring dbus in each
application process' space, which is not that nice...
* Gain management signals and functions are redundant with equivalent
ALSA&GStreamer functions.

I hope this will bring some light on the expected use of those methods/signals...

Cheers,

Fabien

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hello Fabien,

The API is not properly design for audio over hci that's why you are confused.
Those methods make no sense as you had mentioned the commands always come from/goes to alsa plugin (we have just one plugin for pcm that should handle any kind of audio device) via unix socket. So a normal scenarios when sco over hci is to CreateHeadset in the very first time, this will salve the device
in the storage so it is no longer necessary to create it anymore. This mean we
don't need any method call to the API to get audio working while in hci mode,
the plugin already works on demand and I currently fixing the concurrent connections when an application want to open the device for playback and capture at same time.
The current API is only useful for audio over PCM, in that case I guess we need
the API methods to be able to control the streams.
We could disable those concurrent method while in hci mode as they probably break
the plugin stream, actually they normally affects only the rfcomm socket because
sco socket got duped in the process so plugin got its own reference that is not
affected by API calls, but anyway this is a not common behavior for a headset.

btw, switching between audio device is currently done by changing its default device.

Luiz Augusto von Dentz
Engenheiro de Computação

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Guys

The API is not properly design for audio over hci that's why you are

there are some parts of the dbus api that would be used even for the hci mode. Disconnecting the headset for example, since there is not an equivalent alsa call. Disconnect/reconnect will likely be handled in a single system gui that is outside the audio app.

We could disable those concurrent method while in hci mode as they probably

we need a way to tell the plugin that the sco (or a2dp) fd has been invalidated, eg when disconnecting. This is broadcast over dbus and also communicated over the socket to the alsa client so the alsa plugin will do something sensible like use the wired audio. (similarly when the headset reconnects during stream playback--the fd is now available and the plugin needs to be told to re-request it)

Brad

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Luiz Augusto,
Thanks for your answers !!

Please find some more comments below.

Oh you're damn right. I knew about this sco over PCM way of doing things, i just completely forgot about it when i read the interface, sorry about that :-(

Oh that's nice :-)

Yes and no. The issue with this approach is that applications need to be modified to work with sco-over-pcm, which is not very nice :-( I guess it could be possible to have the pcm_bluetooth ALSA plugin to be used even in sco over PCM case, using the ALSA device as slave pcm. What do you think of thus idea ?

Indeed, and according to HSP/HFP specs, the sco channel is supposed to be closed before the RFCOMM one...

Btw, sorry to ask again : has anybody an explanation on the reason for the Gain management signals&functions ?

Cheers,

Fabien

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Fabien

Btw, sorry to ask again : has anybody an explanation on the reason for

gain management might be harder to justify with an example but I think the idea is to keep the ipc and dbus apis as similar as possible.

brad

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Ok, thanks for that. :-) I'm gonna start building on top of these assumptions then :-)

Cheers,

Fabien

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Fabien,

Yep, you are right we cannot stop application using alsa plugin while in PCM mode,
Im not so familiar with alsa so I have no clue about slave pcm, but if we can make
it to just open/close the device (the only thing left in PCM mode) that is the way
to go.

Another point I would like to discuss is about not having the intermediate state when
we are connected to the rfcomm but not yet to the sco socket, it seems useless
to have to Connect() and then Play(), the alsa plugin already goes direct to Play the
stream. Do you guys see any value in having a device connected but not streaming?

Luiz Augusto von Dentz
Engenheiro de Computação

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Luiz

When no device is connected, the plugin will discard or (more preferably) send audio to the wired device. We use connected as a cue that the user wants to use that device for audio.

Are your latest developments in cvs these days or do I need to check git?

Brad

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Brad,

It is on cvs already, about the plugin I guess we cannot simple switch to wired device if we do that we probably leave the application using it with no clue that it switch to wired device on purposed. The routing stuff in my opinion belong to the system audio server (pulse, esd), they could provide a good ui in witch we can configure the fallback device depend on various situations, if we do the rerouting on plugin we would break those configurations.

Luiz Augusto von Dentz
Engenheiro de Computação

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Brad,

no and NO. The Bluetooth plugin is not dealing with any wire connection. The plugin has to be simple and can actually be stupid. I don't wanna have any intelligence inside the ALSA plugin.

Regards

Marcel

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi all,

If the ALSA plugin is not dealing with any wire connection, then wired/wireless handover has to be performed somewhere else. :-) Somewhere else should not be the bt audio daemon. Do you imagine what will happen when new type of wireless headsets will come out of the hood (Wireless USB, Wireless whatever else will happen in the future :-) ) ? Will we be adding audio daemons on top of each other so that each one has the option to perform its on routing business ?

I think we need:
- Either to let the application perform routing operations (that
would make sense in Linux Smartphone style devices, where you have a very reduced set of applications : phone application, media player)
- Either perform the audio routing at the system level (desktop PC
case), the best candidate today being a sound server like pulseaudio.

What do you guys think of that ?
(+1 for pulseaudio for Luiz i think ;-) )

Cheers,

Fabien

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Fabien,

I imagine that even the smartphone has some kind of audio server on them.

-- =

Luiz Augusto von Dentz
Engenheiro de Computa=E7=E3o

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Then maybe your imagination is too powerfull :-)
It's not uncommon for telephony applications to manage directly the audio path... how they will be implemented on Linux is still to be seen though :-)

Cheers,

Fabien

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi,

In the smartphone scenario, there are some streams that are not handled by the processor. This is typically the case if you have a phone module wired to the bluetooth pcm. Today's smartphones even have a hardware routing chip capable of mixing and routing streams. Example inputs are radio and phone module, example outputs are speaker, loudspeaker, earphone and bluetooth.

The audio router should be able to take these streams into account. Having a separate global audio routing would be very flexible. This would allow to fit a large number of hardware platforms.

Last, there should be a way to distinguish between different streams natures : for example an alert should not interfere with a voip call .

BR,
Frederic

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Frederic,

Ok, let's take those into account.
What you're talking about are basically capabilities that are common on proprietary systems but that are still stranger to the free Linux world :-)

Hopefully one day there will be a free implementation of such an audio routing system. The closest effort i would see is pulseaudio, however it looks like it's really far behind in term of routing features :-(

So i guess your answer is also +1 for global routing daemon/system or whatever :-)

Cheers,

Fabien

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Guys

pulse would handle this nicely without a lot of smarts in its bt plugin. My thinking was we would get a "poor man's" sort of routing audio server by doing some tricks in alsa, but maybe it's just too gross :)

Brad

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Having played with the beast a while ago i had the same feeling. :-) Pulseaudio seems to have all the needed bits to handle this task without too much work on the bt side...

Maybe we can offer two things :
- no smart routing at all : use bt audio daemon + alsa plugin
- smart routing : use bt audio daemon + pulseaudio

I even have the feeling that with a properly defined unix IPC interface between the bt audio daemon and the plugin it would be possible to replace the plugin with gstreamer bt element/or even whatever other proprietary sound server smartphone designers would like to use :-)

Cheers,

Fabien

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi all,

It is already possible to use the plugin with gstreamer, you just need to set the device property to "bluetooth". So my guess it that alsa already fulfill our need of system wide mechanism to access bt audio.

This is the command line I use to play mp3 with gstreamer:
gst-launch -v filesrc location="path_to.mp3" ! decodebin ! audioconvert ! audioresample ! alsasink device=bluetooth sync=false

ps: replace "bluetooth" with "a2dpd" or "headset" to use plugins from plugz. I also discribe how to use the plugin in other players here:
http://wiki.bluez.org/wiki/HOWTO/AudioDevices

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Luiz,

Sure it is possible, but it is not the more powerfull way of doing it. In this case your format converting path is MP3 --> PCM -->SBC, which is not good for sound quality, nor for power consumption ;-) You need the power of Gstreamer in order to stream MP3 directly to the headset : you need a native Gstreamer bluetooth element.

Cheers,

Fabien

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

In a desktop situation, you will want to mix streams this is not possible using mp3.
Lots of a2dp devices do not handle mp3. And what if your music is not mp3 encoded, say ogg?

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi again,

Yep, but Fabien probably mean that we gain more flexibility by having some native elements on gstreamer, and I agree with that. One of the problems that Im afraid of is the plugin having to handle encoding/decoding by it own when we could just use a framework to do that for us. Because that I think it would be good to have a set of elements on gstreamer(btaudiosrc, btaudiosink...)
Btw, my plan is not limited with the current device we have in the market, it should be good if we think in something more advanced with a support for various codecs and not limited by stereo headset we have, why not be able to create a home theater 5.1 wireless system.

-- =

Luiz Augusto von Dentz
Engenheiro de Computa=E7=E3o

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

In my opinion the native elements wouldn't do any encoding/decoding
work: this is clearly GStreamer Job as a media converting framework. I think we would have to:
- extend the already included RTP GStreamer element to accept sbc and
mp3 encoded streams.
- wrap libsbc into a GStreamer element to do convert to do PCM to sbc.
- create an a2dp Gstreamer element

..and that's all...
Then any enabled GStreamer application would be able to natively stream mp3, or stream whatever other format using sbc. :-)

Cheers,

Fabien

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi

Although this is really cool to deliver mp3 to the headset (less cpu load, less transcoding noise), it might go too far down the road of an early optimization for the case of a single audio client.

Mikko L at Nokia basically said they wouldn't consider anything along these lines since it gets so complicated when a system sound needs to interrupt mp3 playback. Do you:

- mix two mp3 streams together (technically possible)
- reconfigure the set for sbc and encode the streams to sbc (best
case is a delay, worst case a crash in the set during reconfiguration)
- stop the mp3 player and play the system sound mp3 instead (tricky)

It doesn't help that there's not much notion of a sound "card" that can natively decode mp3. The audio servers don't account for this possibility at all.

Brad

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Brad,

I wont consider going with gstreamer set of elements instead of an alsa plugin for system wide, as you said we might have some technical challengers and as a sound "card" this is not exactly a good idea. So as a system wide solution we must have a alsa plugin that just deliver sbc codec.

A future work perhaps we may be possible to deliver something more flexible to application, but in this case application would have to handle the stream by it' s own.

Why Im already considering this advanced usage? We have an ipc system that should be flexible enough to be able to work with those applications. I guess it should be possible for someone to add native support for multimedia frameworks such as gstreamer, but the support itself is outside the scope of bluez.

-- =

Luiz Augusto von Dentz
Engenheiro de Computa=E7=E3o

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi All,

Please find below some comments

I agree with you : none of those are acceptable. However you may have missed something : MP3 is not to be used as an output format if bluetooth is plugged to a sound mixing daemon :-).
In this case SBC is to be used :-)

The only valid case of MP3 streaming is the one when you build a dedicated audio path between the application(multimedia player) and the hardware device(bt headset). In this case there is no notion of "system sounds" that would appear and would need to be mixed in :-)

My remark was not one against the other.
Obviously there are so many ALSA applications that an ALSA option is a must have. :-)
However a decicated gstreamer support would be nice to have, too.

, as you said we might have some

Agreed. Alsa plugin should implement sbc codec only (no mp3 needed here :-) )

Like a GStreamer based application for instance, that is already used to build its own media pipeline :-)

Agreed. We should be able to plug whatever system using this ipc mechanism, including:
- an ALSA plugin
- a GStreamer bt element
- a sound server

I guess one of those days i'm gonna hack a gstreamer element just for fun :-)... and to prove it's feasible :-)

Cheers,

Fabien

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Fabien

ok... this makes sense. I started hacking the old "a2play" to detect the mp3 decoder but never did get it to send mp3 directly. A symbian developer told me he would have a whack at it but I never heard if it worked for him.

especially if you are trying to do something that is too complicated for alsa.

some of the guys at the uni in Brazil told me the same thing :)

Brad

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Frederic, i agree with you. :-)
But Gstreamer allows to handle all those format conversion issues transparently.
The BT GStreamer element would simply have to declare what formats are supported by the headset (mp3, sbc, ...) with bitrates, channels ... . GStreamer would perform adhoc convertion on a needed basis.

However GStreamer is not meant to replace ALSA, but be used in parallel to it.

Cheers,

Fabien

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Having both is ok for me. Having mp3 support could be a additional feature even with it's limitations.

I'm looking at pulse audio, it is seems very well designed. Does it support non pcm streams ?

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

I agree with that :-)

Im afraid not :-( (but don't take my word, i could be wrong on that)

Cheers,

Fabien Chevalier

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Yes that's possible :-)
We just have to make the hardware pcm a slave of the headset pcm. This basically mean that we would have to call the alsa API function inside each bluetooth PCM plugin function, except for open/close/start/stop.

In this case we can kiss Play()/Stop() byebye :-)

Yes there is *great* value to this.
There are multiple uses to it:
* Basically in the long term Connect() could be called by a GUI. That
would trigger the bluetooth audio deamon to notify a sound routing daemon that rerouting the audio is now an option. Sound routing deamon would then call Play() or whatever else if it chooses to use the newly available device. [Note : this is just an option, i'm not saying here that's what's gonna be done :-)]
* Another reason is that bluetooth audio daemon has to be able to
accept incoming RFCOMM connection from the headset. In this case there is no need to call Connect(), but we can go straight to play mode.

So yes that's *very* important :-), RFCOMM connected but not SCO yet is a valid state.

Cheers,

Fabien

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel