Re: [Bluez-devel] CVS audio-api.txt : 1st question

Luiz Augusto von Dentz
2007-06-29T18:10:28Z

[-- Attachment #1.1: Type: text/plain, Size: 3518 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 4094 bytes --]

[-- Attachment #2: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]