Marcel,
Can we discuss the audio dbus api some more?
fwiw, I'm not sure how to break away from the need to specify the
profile for the case of a combo a2dp/sco device.
I'm focusing on routing "voice" (2-way audio) as a first priority. I
don't provide methods for adding and removing SCO from the voice route
since that's implied by connect/disconnect.
If this looks good I'll start boiling down HSP/HFP methods & signals.
Audio hierarchy (experimental)
==============================
Service org.bluez
Interface org.bluez.Audio
Methods array{string} ListDevices()
Return array of bdaddr strings for each audio
device we have paired with.
void Connect(string identifier, string profile)
Opens the control connection to an audio device.
Will not open the audio channel until requested
by the audio plugin or directly from the
application.
void Disconnect(string identifier, string profile)
Stops audio if it was playing and closes the
control connection to the audio device.
void Play(string identifier, string profile)
Opens the audio stream. Called from the audio
plugin or from the application if audio is
routed somewhere other than the daemon (eg
through PCM, direct to the DSP).
void Stop(string identifier, string profile)
void Pause(string identifier, string profile)
void Resume(string identifier, string profile)
void SetIdleDisconnect(string identifier, string profile, int32 delay)
Set the idle Stop for the device.
Only applicable when audio is routed through the
daemon. Stop the stream and emit a signal if
delay seconds pass without any audio being sent
to the daemon from an application. A value of 0
indicates no idle stop; this is the default.
int32 GetIdleDisconnect(string identifier, string profile)
int32 GetVolume(string identifier, string profile)
void SetVolume(string identifier, string profile, int32 volume)
Volume is 0..15
void ChangeVolume(string identifier, string profile, int16 delta)
delta is +1 or -1
void AddWiredVoice()
Add wired audio output to the voice routing rule
void RemoveWiredVoice()
Remove wired audio output from the voice routing
rule
Signals void Connected()
Indicate device and profile.
void Disconnected()
Indicate device and profile.
void Played()
Indicate device and profile.
void Stopped()
Indicate device and profile.
void Paused()
Indicate device and profile.
void Resumed()
Indicate device and profile.
void IdleStopChanged()
Indicate the new idle, device, profile
void VolumeSet()
Indicate new volume, device, profile.
void VolumeChanged()
Indicate +1 or -1, device, profile.
void WiredVoiceAdded()
Indicated when wired audio is added to the
voice route, also automatically when a SCO
set is disconnected.
void WiredVoiceRemoved()
Indicated when wired audio is removed from
the voice route, also automatically when a
SCO set is connected.
Brad
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Brad Midgley wrote:
> Fabien
>
>> Could you provide details on why you think this was needed ?
>
> The primary reason for a timeout is to hold the audio stream open for a
> little while after the application closes it, in case it will be used
> again soon. Under the original a2dp plugin, one a2dp set I had would
> lock up when xine rapidly opened/closed/opened/closed/opened the alsa
> device on startup.
Ok, i understood this time. :-)
Indeed i 100% agree with the behaviour that it is required, unless we
intend to fix one by one all the applications.
>
> There's also delay in bringing up audio that we want to avoid if
> possible since it results in the start of the stream being lost. System
> sounds tend to get lost this way.
Yes. I agree with that too.
Cheers,
Fabien
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Fabien
> Could you provide details on why you think this was needed ?
The primary reason for a timeout is to hold the audio stream open for a
little while after the application closes it, in case it will be used
again soon. Under the original a2dp plugin, one a2dp set I had would
lock up when xine rapidly opened/closed/opened/closed/opened the alsa
device on startup.
There's also delay in bringing up audio that we want to avoid if
possible since it results in the start of the stream being lost. System
sounds tend to get lost this way.
Brad
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Brad,
>>> I didn't want the timeout to default to be on since it's only useful in
>>> the case when audio goes over hci.
>> Looks like you lost me there :-(, i didn't understand your last sentence
>
> we may have to modify this timeout plan. What I wanted was for the
> daemon to see when audio transmission was idle and have it put the state
> into "stopped" and close the sco or a2dp audio connection. The plugin
> would be notified via dbus that this had happened.
Ok, i understand this time :-)
However i'm surprised you thought of this can where an application would
just stop sending data, as it's not possible to happen.
ALSA applications are expected to call snd_pcm_pause() if they want to
stop sending data without closing the stream. In practive this is rarely
used, as not all hardware support this feature.
If they don't call snd_pcm_pause(), an underrun will occur, which must
be handle as an error later (i.e. hardware is then in an inconsistent
state).
Could you provide details on why you think this was needed ?
Cheers,
Fabien
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Fabien
>>>>> int32 GetIdleDisconnect(string identifier, string profile)
>>> Brad : How are we supposed to handle the case when an application
>>> crashes while sending audio data ? Will he have to keep the audio
>>> channel opened forever ?
>> if the disconnect timout is set then after the timeout passes the sco
>> connection will be closed.
>>
>> I didn't want the timeout to default to be on since it's only useful in
>> the case when audio goes over hci.
>
> Looks like you lost me there :-(, i didn't understand your last sentence
we may have to modify this timeout plan. What I wanted was for the
daemon to see when audio transmission was idle and have it put the state
into "stopped" and close the sco or a2dp audio connection. The plugin
would be notified via dbus that this had happened.
We should work out a plan so the daemon knows when an app is actively
sending audio even if the daemon is not processing that audio directly.
> Brad, could you provide some details on that ?
> If i read your schematic correctly, there is a GUI that allows user to
> choose between PCM and headset routing.
> If this is what it is supposed to do, then it is possible to do it at
> ALSA level without having to write any code :
>
> Users would have to add that in their ~/.asoundrc for instance
>
> pcm.!default {
> type dmix
> slave.pcm "a2dpd"
> }
>
> And this would switch their default output to be the headset.
> Of course it is possible to write a program that automates that so that
> people don't have to dig in their configuration files.
the advantage of using dbus communicating to an alsa plugin is the
change (for example) from built-in audio to sco bluetooth audio can take
effect in the middle of a voip call without the voip app needing to know
anything special happened.
Brad
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Brad,
>
>>>> int32 GetIdleDisconnect(string identifier, string profile)
>> Brad : How are we supposed to handle the case when an application
>> crashes while sending audio data ? Will he have to keep the audio
>> channel opened forever ?
>
> if the disconnect timout is set then after the timeout passes the sco
> connection will be closed.
>
> I didn't want the timeout to default to be on since it's only useful in
> the case when audio goes over hci.
Looks like you lost me there :-(, i didn't understand your last sentence
>
>> Marcel, could you provide details on all this PCM routing stuff ?
>> ALSA already has support for routing aufio through the use of audio plugins.
>> Maybe it's a bit redundant ?
>
> I was the one who brought up routing. I want the daemon to store enough
> state so the alsa plugin can figure out where audio goes.
Brad, could you provide some details on that ?
If i read your schematic correctly, there is a GUI that allows user to
choose between PCM and headset routing.
If this is what it is supposed to do, then it is possible to do it at
ALSA level without having to write any code :
Users would have to add that in their ~/.asoundrc for instance
pcm.!default {
type dmix
slave.pcm "a2dpd"
}
And this would switch their default output to be the headset.
Of course it is possible to write a program that automates that so that
people don't have to dig in their configuration files.
Cheers,
Fabien
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Brad
> in progress. I'd much rather have Answered() and Playing() always
> signaled together regardless of the ring type used to indicate the call.
Hmm. This was not such a good example actually... the app needs to get
Playing() so it knows when it can start transmitting the custom ring.
I still like having special states for incoming calls.
Brad
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel
>>>> void RingHeadset()
>>>>
>>>> Indicate a single RING to the connected headset.
>>> No need to do this. This should be handled automatically via Play or
>>> some other method.
It looks like RING could be sent when sco is up but probably is not a
good idea.
I've been reading through HFP more and I think we need special states
for both kinds of incoming calls: custom ring and builtin ring. If we
don't use special states then the use cases are very different--in the
custom ring case, it means Playing() will be signaled before the call is
in progress. I'd much rather have Answered() and Playing() always
signaled together regardless of the ring type used to indicate the call.
Headset hierarchy (experimental)
==============================
Service org.bluez
Interface org.bluez.Headset
Methods void Connect(string identifier)
Opens the control connection to an audio device.
Will not open the audio channel until requested
by the audio plugin or directly from the
application.
void Disconnect(string identifier)
Stops audio if it was playing and closes the
control connection to the audio device.
void Play(string identifier)
Opens the audio stream. Called from the audio
plugin or from the application if audio is
routed somewhere other than the daemon (eg
through PCM, direct to the DSP).
void Stop(string identifier)
void Pause(string identifier)
void Resume(string identifier)
void SetTimeout(string identifier, uint32 timeout)
Set the idle Stop for the device.
Only applicable when audio is routed through the
daemon. Stop the stream and emit a signal if
timeout elapses without any audio being sent
to the daemon from an application. A value of 0
indicates no idle stop; this is the default.
uint32 GetTimeout(string identifier)
uint16 GetSpeakerGain(string identifier)
uint16 GetMicrophoneGain(string identifier)
void SetSpeakerGain(string identifier, uint16 gain)
Gain is 0..15
void SetMicrophoneGain(string identifier, uint16 gain)
Gain is 0..15
void Ring()
Uses the headset's builtin ringer and go into
ringing state to indicate an incoming call.
void CustomRing()
Brings up the audio connection (similar to the
playing state) to indicate a custom ring tone
and go into custom ringing state.
void CancelRinging()
Cancel ringing or custom ringing incoming call.
Signals void Connected()
Indicate device and profile.
void Disconnected()
Indicate device and profile.
void Playing()
Indicate device and profile.
void Stopped()
Indicate device and profile.
void Paused()
Indicate device and profile.
void Resumed()
Indicate device and profile.
void Ringing()
Headset is in ringing state. RING will be
sent every 3 seconds.
void CustomRinging()
Headset is in custom ringing state. Application
may now send custom ring tone.
void Answered()
User answered a call so ringing or custom
ringing state will go to playing state.
void Ignored()
User ignored a call.
void Canceled()
Ringing call was canceled.
void TimeoutChanged()
Indicate the new idle, device, profile
void SpeakerGainChanged()
Indicate new gain, device, profile.
void MicrophoneGainChanged()
Indicate new gain, device, profile.
void HeadsetButtonPressed()
Indicates the headset button was pressed.
void RedialButtonPressed()
Indicates the headset requested the last number
redialed.
Brad
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi,
On Thu, Nov 16, 2006, Marcel Holtmann wrote:
> > void RingHeadset()
> >
> > Indicate a single RING to the connected headset.
>
> No need to do this. This should be handled automatically via Play or
> some other method.
I think it's needed, or at least it can't be handled through the Play
method. The "Send Ring to headset, get answer button press from headset"
situation is not necessarely related to sending and receiving audio in
general.
Johan
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Fabien
> Why not keep it simple and keep a2dp for what it is designed for :
> listening to high quality music ?
I'm not suggesting we make people use a2dp for voip. I want us to come
up with a flexible architecture that is future-proof and provides a
simple way for the user to decide how to use things.
There's something to be said for having a default system-wide audio
setup and not making users go into each app and change its settings
because of the obscure nature of the different transports.
brad
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Fabien
>>> int32 GetIdleDisconnect(string identifier, string profile)
>
> Brad : How are we supposed to handle the case when an application
> crashes while sending audio data ? Will he have to keep the audio
> channel opened forever ?
if the disconnect timout is set then after the timeout passes the sco
connection will be closed.
I didn't want the timeout to default to be on since it's only useful in
the case when audio goes over hci.
> Marcel, could you provide details on all this PCM routing stuff ?
> ALSA already has support for routing aufio through the use of audio plugins.
> Maybe it's a bit redundant ?
I was the one who brought up routing. I want the daemon to store enough
state so the alsa plugin can figure out where audio goes.
Brad
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
> hmm... this is actually for interacting with the builtin speaker. Johan
> mentioned the scenario of custom ringing both the headset and the
> speaker simultaneously and there are other scenarios we would need to
> interact with builtin audio (for example, to get a mic input with
> today's a2dp headsets you would use the built-in mic)
Guys, i wouldn't like to be a pain in the ass, but i have an annoying
question to ask ;-)
Why not keep it simple and keep a2dp for what it is designed for :
listening to high quality music ?
a2dp has never been designed for low latency, the codecs used will add
way too much delay to be of any use for real time audioconferencing or
videoconferencing.
It's what i've learned while talking with some phone guys : it looks
like a2dp will never ever be used for audio calls, due to the latency
introduced by sbc or mp3. :-(
Cheers,
Fabien
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel & Brad, please find a few questions below:
> Hi Brad,
>
>> fwiw, I'm not sure how to break away from the need to specify the
>> profile for the case of a combo a2dp/sco device.
>
> I am still not convinced that we need to do this kind of things,
Marcel, what do you mean by 'this kind of things' ?
but if
> you really wanna separate this, then we need a more general approach. In
> case of A2DP it can happen that we have two or even more independent
> channels (I know that no such device exists at the moment).
>
> So what you need is some kind of capabilities command and then you can
> use this to create instances for all devices. So my proposal would be
> that we use org.bluez.Audio as a configuration interface (like Manager)
> and then org.bluez.Headset to actually connect, disconnect etc.
>
>> Audio hierarchy (experimental)
>> ==============================
>>
>> Service org.bluez
>> Interface org.bluez.Audio
>>
>> Methods array{string} ListDevices()
>>
>> Return array of bdaddr strings for each audio
>> device we have paired with.
>>
>> void Connect(string identifier, string profile)
>>
>> Opens the control connection to an audio device.
>> Will not open the audio channel until requested
>> by the audio plugin or directly from the
>> application.
>>
>> void Disconnect(string identifier, string profile)
>>
>> Stops audio if it was playing and closes the
>> control connection to the audio device.
>>
>> void Play(string identifier, string profile)
>>
>> Opens the audio stream. Called from the audio
>> plugin or from the application if audio is
>> routed somewhere other than the daemon (eg
>> through PCM, direct to the DSP).
>>
>> void Stop(string identifier, string profile)
>>
>> void Pause(string identifier, string profile)
>>
>> void Resume(string identifier, string profile)
>>
>> void SetIdleDisconnect(string identifier, string profile, int32 delay)
>>
>> Set the idle Stop for the device.
>>
>> Only applicable when audio is routed through the
>> daemon. Stop the stream and emit a signal if
>> delay seconds pass without any audio being sent
>> to the daemon from an application. A value of 0
>> indicates no idle stop; this is the default.
>>
>> int32 GetIdleDisconnect(string identifier, string profile)
Brad : How are we supposed to handle the case when an application
crashes while sending audio data ? Will he have to keep the audio
channel opened forever ?
>
> Timeouts must be in uint32 and name them "timeout". Delay would be used
> in case a process is sent to sleep.
>
>> int32 GetVolume(string identifier, string profile)
>>
>> void SetVolume(string identifier, string profile, int32 volume)
>>
>> Volume is 0..15
>
> And for what reason is this int32. First of all it must be unsigned and
> 16-bit seem to be enough.
>
>> void ChangeVolume(string identifier, string profile, int16 delta)
>>
>> delta is +1 or -1
>
> No. Use IncreaseVolume and DecreaseVolume.
>
>> void AddWiredVoice()
>>
>> Add wired audio output to the voice routing rule
>>
>> void RemoveWiredVoice()
>>
>> Remove wired audio output from the voice routing
>> rule
>
> Not needed at all. This is not our business and the PCM routing will be
> a parameter to the daemon. No need to support PCM and HCI routing at the
> same time.
Marcel, could you provide details on all this PCM routing stuff ?
ALSA already has support for routing aufio through the use of audio plugins.
Maybe it's a bit redundant ?
Cheers,
Fabien
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel
>>hmm... this is actually for interacting with the builtin speaker. Johan
>>mentioned the scenario of custom ringing both the headset and the
>>speaker simultaneously and there are other scenarios we would need to
>>interact with builtin audio (for example, to get a mic input with
>>today's a2dp headsets you would use the built-in mic)
>
> This will be up to ALSA or GStreamer. It is not the job of the audio
> daemon to handle non-Bluetooth stuff.
I'm in agreement that bt.audiod does not do any built-in audio i/o, but
can it just keep track of when builtin audio is needed? I figure the
alsa or gst plugin will use dbus to get this state from bt.audiod and
act on it.
I tried to think of a way to not involve bt.audiod at all and I'm not
coming up with another approach.
Brad
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Brad,
> >> void RingHeadset()
> >>
> >> Indicate a single RING to the connected headset.
> >
> > No need to do this. This should be handled automatically via Play or
> > some other method.
>
> Play will always open the sco channel without waiting for the user to
> hit the button so it can't be overloaded to do ringing.
>
> Would you like it better if we used a ringing state instead of sending a
> single ring? Should custom ring (open sco, send ring sound, wait for
> button press) and HSP ring (send RING on rfcomm channel) be combined
> together somehow?
need to check in what states are RING can be sent. I think it would not
be needed, but we will see.
> >> void PressHeadsetButton()
> >>
> >> Indicate a button press to the connected audio
> >> gateway.
> >
> > Unneeded. We are not in the role of a headset.
>
> right. I will save this for org.bluez.AudioGateway or whatever we call it.
>
> That brings up another question. Do you want one interface to do
> handsfree and headset or do we have one interface for each? I was
> imagining combining them but I need to read through HFP to be sure.
We will have one interface for Headset, Handsfree and A2DP. There is no
difference between expect the voice quality.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel
> This will be up to ALSA or GStreamer. It is not the job of the audio
> daemon to handle non-Bluetooth stuff.
Ok.
>> void RingHeadset()
>>
>> Indicate a single RING to the connected headset.
>
> No need to do this. This should be handled automatically via Play or
> some other method.
Play will always open the sco channel without waiting for the user to
hit the button so it can't be overloaded to do ringing.
Would you like it better if we used a ringing state instead of sending a
single ring? Should custom ring (open sco, send ring sound, wait for
button press) and HSP ring (send RING on rfcomm channel) be combined
together somehow?
>> void PressHeadsetButton()
>>
>> Indicate a button press to the connected audio
>> gateway.
>
> Unneeded. We are not in the role of a headset.
right. I will save this for org.bluez.AudioGateway or whatever we call it.
That brings up another question. Do you want one interface to do
handsfree and headset or do we have one interface for each? I was
imagining combining them but I need to read through HFP to be sure.
Brad
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Brad,
> > So what you need is some kind of capabilities command and then you can
> > use this to create instances for all devices. So my proposal would be
> > that we use org.bluez.Audio as a configuration interface (like Manager)
> > and then org.bluez.Headset to actually connect, disconnect etc.
>
> Ok... whatever it takes so the Play method is not ambiguous. I was
> preparing to do all kinds of acrobatics to figure out what was intended
> when changing the volume without a device connected but with the manager
> idea that won't be so complicated.
>
> I have looked over Manager but I need to examine the code to get a
> better feel for this.
you basically differentiate the various attached headsets via different
object paths on D-Bus. So every headset is its own object.
> > No. Use IncreaseVolume and DecreaseVolume.
>
> I was looking over my notes and the HSP profile and couldn't see the
> need for these. I left them out but do we need them? Do we treat mic
> gain this way too?
>
> I started using Gain below instead of Volume since it applies to both
> speaker and mic.
I don't care. My point was that we don't use a direction parameter.
> >> void AddWiredVoice()
> >>
> >> Add wired audio output to the voice routing rule
> >>
> >> void RemoveWiredVoice()
> >>
> >> Remove wired audio output from the voice routing
> >> rule
> >
> > Not needed at all. This is not our business and the PCM routing will be
> > a parameter to the daemon. No need to support PCM and HCI routing at the
> > same time.
>
> hmm... this is actually for interacting with the builtin speaker. Johan
> mentioned the scenario of custom ringing both the headset and the
> speaker simultaneously and there are other scenarios we would need to
> interact with builtin audio (for example, to get a mic input with
> today's a2dp headsets you would use the built-in mic)
This will be up to ALSA or GStreamer. It is not the job of the audio
daemon to handle non-Bluetooth stuff.
> Headset hierarchy (experimental)
> ==============================
>
> Service org.bluez
> Interface org.bluez.Headset
>
> Methods void Connect(string identifier)
>
> Opens the control connection to an audio device.
> Will not open the audio channel until requested
> by the audio plugin or directly from the
> application.
>
> void Disconnect(string identifier)
>
> Stops audio if it was playing and closes the
> control connection to the audio device.
>
> void Play(string identifier)
>
> Opens the audio stream. Called from the audio
> plugin or from the application if audio is
> routed somewhere other than the daemon (eg
> through PCM, direct to the DSP).
>
> void Stop(string identifier)
>
> void Pause(string identifier)
>
> void Resume(string identifier)
>
> void SetTimeout(string identifier, uint32 timeout)
>
> Set the idle Stop for the device.
>
> Only applicable when audio is routed through the
> daemon. Stop the stream and emit a signal if
> timeout elapses without any audio being sent
> to the daemon from an application. A value of 0
> indicates no idle stop; this is the default.
>
> uint32 GetTimeout(string identifier)
>
> uint16 GetSpeakerGain(string identifier)
>
> uint16 GetMicrophoneGain(string identifier)
>
> void SetSpeakerGain(string identifier, uint16 gain)
>
> Gain is 0..15
>
> void SetMicrophoneGain(string identifier, uint16 gain)
>
> Gain is 0..15
>
> void AddWiredVoice()
>
> Add wired audio output to the voice routing rule
>
> void RemoveWiredVoice()
>
> Remove wired audio output from the voice routing
> rule
As mentioned above. I don't see the need for these two.
> void RingHeadset()
>
> Indicate a single RING to the connected headset.
No need to do this. This should be handled automatically via Play or
some other method.
> void PressHeadsetButton()
>
> Indicate a button press to the connected audio
> gateway.
Unneeded. We are not in the role of a headset.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel
> So what you need is some kind of capabilities command and then you can
> use this to create instances for all devices. So my proposal would be
> that we use org.bluez.Audio as a configuration interface (like Manager)
> and then org.bluez.Headset to actually connect, disconnect etc.
Ok... whatever it takes so the Play method is not ambiguous. I was
preparing to do all kinds of acrobatics to figure out what was intended
when changing the volume without a device connected but with the manager
idea that won't be so complicated.
I have looked over Manager but I need to examine the code to get a
better feel for this.
> No. Use IncreaseVolume and DecreaseVolume.
I was looking over my notes and the HSP profile and couldn't see the
need for these. I left them out but do we need them? Do we treat mic
gain this way too?
I started using Gain below instead of Volume since it applies to both
speaker and mic.
>
>> void AddWiredVoice()
>>
>> Add wired audio output to the voice routing rule
>>
>> void RemoveWiredVoice()
>>
>> Remove wired audio output from the voice routing
>> rule
>
> Not needed at all. This is not our business and the PCM routing will be
> a parameter to the daemon. No need to support PCM and HCI routing at the
> same time.
hmm... this is actually for interacting with the builtin speaker. Johan
mentioned the scenario of custom ringing both the headset and the
speaker simultaneously and there are other scenarios we would need to
interact with builtin audio (for example, to get a mic input with
today's a2dp headsets you would use the built-in mic)
Headset hierarchy (experimental)
==============================
Service org.bluez
Interface org.bluez.Headset
Methods void Connect(string identifier)
Opens the control connection to an audio device.
Will not open the audio channel until requested
by the audio plugin or directly from the
application.
void Disconnect(string identifier)
Stops audio if it was playing and closes the
control connection to the audio device.
void Play(string identifier)
Opens the audio stream. Called from the audio
plugin or from the application if audio is
routed somewhere other than the daemon (eg
through PCM, direct to the DSP).
void Stop(string identifier)
void Pause(string identifier)
void Resume(string identifier)
void SetTimeout(string identifier, uint32 timeout)
Set the idle Stop for the device.
Only applicable when audio is routed through the
daemon. Stop the stream and emit a signal if
timeout elapses without any audio being sent
to the daemon from an application. A value of 0
indicates no idle stop; this is the default.
uint32 GetTimeout(string identifier)
uint16 GetSpeakerGain(string identifier)
uint16 GetMicrophoneGain(string identifier)
void SetSpeakerGain(string identifier, uint16 gain)
Gain is 0..15
void SetMicrophoneGain(string identifier, uint16 gain)
Gain is 0..15
void AddWiredVoice()
Add wired audio output to the voice routing rule
void RemoveWiredVoice()
Remove wired audio output from the voice routing
rule
void RingHeadset()
Indicate a single RING to the connected headset.
void PressHeadsetButton()
Indicate a button press to the connected audio
gateway.
Signals void Connected()
Indicate device and profile.
void Disconnected()
Indicate device and profile.
void Playing()
Indicate device and profile.
void Stopped()
Indicate device and profile.
void Paused()
Indicate device and profile.
void Resumed()
Indicate device and profile.
void TimeoutChanged()
Indicate the new idle, device, profile
void SpeakerGainChanged()
Indicate new gain, device, profile.
void MicrophoneGainChanged()
Indicate new gain, device, profile.
void WiredVoiceAdded()
Indicated when wired audio is added to the
voice route, also automatically when a SCO
set is disconnected.
void WiredVoiceRemoved()
Indicated when wired audio is removed from
the voice route, also automatically when a
SCO set is connected.
void HeadsetRang()
Indicates the audio gateway has sent a ring.
void HeadsetButtonPressed()
Indicates the headset button was pressed.
Brad
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Brad,
> fwiw, I'm not sure how to break away from the need to specify the
> profile for the case of a combo a2dp/sco device.
I am still not convinced that we need to do this kind of things, but if
you really wanna separate this, then we need a more general approach. In
case of A2DP it can happen that we have two or even more independent
channels (I know that no such device exists at the moment).
So what you need is some kind of capabilities command and then you can
use this to create instances for all devices. So my proposal would be
that we use org.bluez.Audio as a configuration interface (like Manager)
and then org.bluez.Headset to actually connect, disconnect etc.
> Audio hierarchy (experimental)
> ==============================
>
> Service org.bluez
> Interface org.bluez.Audio
>
> Methods array{string} ListDevices()
>
> Return array of bdaddr strings for each audio
> device we have paired with.
>
> void Connect(string identifier, string profile)
>
> Opens the control connection to an audio device.
> Will not open the audio channel until requested
> by the audio plugin or directly from the
> application.
>
> void Disconnect(string identifier, string profile)
>
> Stops audio if it was playing and closes the
> control connection to the audio device.
>
> void Play(string identifier, string profile)
>
> Opens the audio stream. Called from the audio
> plugin or from the application if audio is
> routed somewhere other than the daemon (eg
> through PCM, direct to the DSP).
>
> void Stop(string identifier, string profile)
>
> void Pause(string identifier, string profile)
>
> void Resume(string identifier, string profile)
>
> void SetIdleDisconnect(string identifier, string profile, int32 delay)
>
> Set the idle Stop for the device.
>
> Only applicable when audio is routed through the
> daemon. Stop the stream and emit a signal if
> delay seconds pass without any audio being sent
> to the daemon from an application. A value of 0
> indicates no idle stop; this is the default.
>
> int32 GetIdleDisconnect(string identifier, string profile)
Timeouts must be in uint32 and name them "timeout". Delay would be used
in case a process is sent to sleep.
> int32 GetVolume(string identifier, string profile)
>
> void SetVolume(string identifier, string profile, int32 volume)
>
> Volume is 0..15
And for what reason is this int32. First of all it must be unsigned and
16-bit seem to be enough.
> void ChangeVolume(string identifier, string profile, int16 delta)
>
> delta is +1 or -1
No. Use IncreaseVolume and DecreaseVolume.
> void AddWiredVoice()
>
> Add wired audio output to the voice routing rule
>
> void RemoveWiredVoice()
>
> Remove wired audio output from the voice routing
> rule
Not needed at all. This is not our business and the PCM routing will be
a parameter to the daemon. No need to support PCM and HCI routing at the
same time.
> Signals void Connected()
>
> Indicate device and profile.
>
> void Disconnected()
>
> Indicate device and profile.
>
> void Played()
>
> Indicate device and profile.
Actually this would be Playing.
> void Stopped()
>
> Indicate device and profile.
>
> void Paused()
>
> Indicate device and profile.
>
> void Resumed()
>
> Indicate device and profile.
>
> void IdleStopChanged()
>
> Indicate the new idle, device, profile
>
> void VolumeSet()
>
> Indicate new volume, device, profile.
Wrong name. This must be VolumeChanged(uint16 volume).
> void VolumeChanged()
>
> Indicate +1 or -1, device, profile.
This must be VolumeIncreased and VolumeDecreased.
> void WiredVoiceAdded()
>
> Indicated when wired audio is added to the
> voice route, also automatically when a SCO
> set is disconnected.
>
> void WiredVoiceRemoved()
>
> Indicated when wired audio is removed from
> the voice route, also automatically when a
> SCO set is connected.
Since we don't need to set this, we also don't need any signals.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel