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
Guys
The API is not properly design for audio over hci that's why you are
> confused.
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
> 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.
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
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 <[email protected]> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
Luiz Augusto von Dentz
Engenheiro de Computa??o
Fabien
> 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).
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.
> However a decicated gstreamer support would be nice to have, too.
especially if you are trying to do something that is too complicated for alsa.
> I guess one of those days i'm gonna hack a gstreamer element just for
> fun :-)... and to prove it's feasible :-)
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
Hi All,
Please find below some comments
>> 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)
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 :-)
>>
>> 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.
>
> I wont consider going with gstreamer set of elements instead of an
> alsa plugin for system wide
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
> 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.
Agreed. Alsa plugin should implement sbc codec only (no mp3 needed here
:-) )
>
> 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.
Like a GStreamer based application for instance, that is already used to
build its own media pipeline :-)
>
> 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.
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 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.
>
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
Hi Brad,
On 7/6/07, Brad Midgley <[email protected]> wrote:
> 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.
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
> 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
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
Luiz Augusto von Dentz wrote:
> Hi again,
>
> On 7/6/07, Frederic Dalleau <[email protected]> wrote:
>>> You need the power of Gstreamer in order to stream MP3 directly to the
>>> headset : you need a native Gstreamer bluetooth element.
>>>
>> 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?
>
> 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
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
Frederic Dalleau wrote:
>> However GStreamer is not meant to replace ALSA, but be used in parallel
>> to it.
>>
> 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.
I agree with that :-)
> Does it
> support non pcm streams ?
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
> However GStreamer is not meant to replace ALSA, but be used in parallel
> to it.
>
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
Frederic Dalleau wrote:
>> You need the power of Gstreamer in order to stream MP3 directly to the
>> headset : you need a native Gstreamer bluetooth element.
>>
> 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?
>
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
Hi again,
On 7/6/07, Frederic Dalleau <[email protected]> wrote:
>
> > You need the power of Gstreamer in order to stream MP3 directly to the
> > headset : you need a native Gstreamer bluetooth element.
> >
> 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?
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
> You need the power of Gstreamer in order to stream MP3 directly to the
> headset : you need a native Gstreamer bluetooth element.
>
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 Luiz,
> 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
>
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
Hi all,
On 7/6/07, Fabien Chevalier <[email protected]> wrote:
> 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 :-)
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
>
>>> 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.
>>>
>> If the ALSA plugin is not dealing with any wire connection, then
>> wired/wireless handover has to be performed somewhere else. :-)
>
> 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 :)
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
Guys
> > 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.
> >
>
> If the ALSA plugin is not dealing with any wire connection, then
> wired/wireless handover has to be performed somewhere else. :-)
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
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
> Hi,
>
>> - Either perform the audio routing at the system level (desktop PC
>> case), the best candidate today being a sound server like pulseaudio.
>>
> 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
>
>
-------------------------------------------------------------------------
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 Augusto von Dentz wrote:
> Hi Fabien,
>
> On 7/5/07, Fabien Chevalier <[email protected]> wrote:
>> 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 ;-) )
>
> I imagine that even the smartphone has some kind of audio server on them.
>
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,
> - Either perform the audio routing at the system level (desktop PC
> case), the best candidate today being a sound server like pulseaudio.
>
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 Fabien,
On 7/5/07, Fabien Chevalier <[email protected]> wrote:
> 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 ;-) )
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
Hi all,
>> 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.
>
> 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.
>
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
Luiz Augusto von Dentz wrote:
> 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.
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 :-)
>
> 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?
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
Hi Brad,
> > stream. Do you guys see any value in having a device connected but not
> > streaming?
>
> 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.
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 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.
On 7/3/07, Brad Midgley <[email protected]> wrote:
>
> Luiz
>
> > stream. Do you guys see any value in having a device connected but not
> > streaming?
>
> 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
>
--
Luiz Augusto von Dentz
Engenheiro de Computa??o
Luiz
> stream. Do you guys see any value in having a device connected but not
> streaming?
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 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
> Fabien
>
> Btw, sorry to ask again : has anybody an explanation on the reason for
> the Gain management signals&functions ?
>
>
> 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.
>
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
Fabien
Btw, sorry to ask again : has anybody an explanation on the reason for
> the Gain management signals&functions ?
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
Hi Luiz Augusto,
Thanks for your answers !!
Please find some more comments below.
> Hello Fabien,
>
> The API is not properly design for audio over hci that's why you are
> confused.
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 :-(
> 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,
Oh that's nice :-)
> 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.
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 ?
> 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.
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