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.

On 6/29/07, Fabien Chevalier < fabchevalier@free.fr> wrote:

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel



--
Luiz Augusto von Dentz
Engenheiro de Computação