From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <2d5a2c100706291110i473d080bv6ba634f0eb8d9deb@mail.gmail.com> Date: Fri, 29 Jun 2007 15:10:28 -0300 From: "Luiz Augusto von Dentz" To: "BlueZ development" In-Reply-To: <46852386.8050608@free.fr> MIME-Version: 1.0 References: <46852386.8050608@free.fr> Subject: Re: [Bluez-devel] CVS audio-api.txt : 1st question Reply-To: BlueZ development List-Id: BlueZ development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0516508528==" Sender: bluez-devel-bounces@lists.sourceforge.net Errors-To: bluez-devel-bounces@lists.sourceforge.net --===============0516508528== Content-Type: multipart/alternative; boundary="----=_Part_81603_16927828.1183140628453" ------=_Part_81603_16927828.1183140628453 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 whe= n sco over hci is to CreateHeadset in the very first time, this will salve th= e 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 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 > --=20 Luiz Augusto von Dentz Engenheiro de Computa=E7=E3o ------=_Part_81603_16927828.1183140628453 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 ment= ioned the commands always
come from/goes to alsa plugin (we have just on= e plugin for pcm that should=20
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 socke= t because
sco socket got duped in the process so plugin got its own refe= rence that is not
affected by API calls, but anyway this is a not commo= n behavior for a headset.

btw, switching between audio device is currently done by changing i= ts default device.

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

Hi Bluez developer,

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

Methods:
--------
void Play()
void Stop()
uint1= 6 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 supp= osed to
be handled by the various ALSA plugins,
that would communicat= e using a dedicated unix socket ?

In fact i'm afraid of the foll= owing issues if those methods/signals are
available:
* An application could use snd_pcm_start to start playin= g, and another
one could shut down the stream using
Stop() : the resu= lt would certainly be an unexpectedly broken stream.
* Application deve= loppers 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 su= pposed to call those method by itself, this
would mean bring dbus in eac= h
application process' space, which is not that nice...
* Gain ma= nagement signals and functions are redundant with equivalent
ALSA&GS= treamer 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/powerba= r/db2/
_______________________________________________
Bluez-deve= l mailing list
Bluez-devel@lists.= sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel



--
Luiz Augusto von De= ntz
Engenheiro de Computa=E7=E3o ------=_Part_81603_16927828.1183140628453-- --===============0516508528== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- 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/ --===============0516508528== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Bluez-devel mailing list Bluez-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel --===============0516508528==--