audio & dbus
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
Marcel Holtmann
maintainerHi Brad,
Quoted 2 lines
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.
Quoted 40 lines
Audio hierarchy (experimental)
==============================Service org.bluez
Interface org.bluez.AudioMethods 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.
Quoted 7 lines
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.
Quoted 5 lines
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.
Quoted 3 lines
void
ChangeVolume(string identifier, string profile, int16 delta)delta is +1 or -1
No. Use IncreaseVolume and DecreaseVolume.
Quoted 8 lines
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.
Quoted 11 lines
Signals void
Connected()Indicate device and profile.
void
Disconnected()Indicate device and profile.
void
Played()Indicate device and profile.
Actually this would be Playing.
Quoted 12 lines
void
Stopped()Indicate device and profile.
void
Paused()Indicate device and profile.
void
Resumed()Indicate device and profile.
Quoted 7 lines
void
IdleStopChanged()Indicate the new idle, device, profile
void
VolumeSet()Indicate new volume, device, profile.
Wrong name. This must be VolumeChanged(uint16 volume).
Quoted 3 lines
void
VolumeChanged()Indicate +1 or -1, device, profile.
This must be VolumeIncreased and VolumeDecreased.
Quoted 11 lines
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
Marcel
Quoted 4 lines
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.
Quoted 1 line
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.
Quoted 5 lines
Quoted 5 lines
void
AddWiredVoice()Add wired audio output to the voice routing rule
Quoted 8 lines
Quoted 4 lines
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
Marcel Holtmann
maintainerHi Brad,
Quoted 5 lines
Quoted 4 lines
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.
Quoted 7 lines
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.
Quoted 8 lines
Quoted 1 line
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.
Quoted 13 lines
Quoted 4 lines
Quoted 4 lines
void
AddWiredVoice()Add wired audio output to the voice routing rule
Quoted 8 lines
Quoted 4 lines
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.
Quoted 5 lines
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.
Quoted 55 lines
Headset hierarchy (experimental)
==============================Service org.bluez
Interface org.bluez.HeadsetMethods 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
Quoted 8 lines
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.
Quoted 3 lines
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.
Quoted 4 lines
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
Hi,
Quoted 6 lines · Marcel Holtmann
Quoted 3 lines
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
Marcel
Quoted 2 lines
This will be up to ALSA or GStreamer. It is not the job of the audio daemon to handle non-Bluetooth stuff.
Ok.
Quoted 6 lines
Quoted 3 lines
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?
Quoted 6 lines
Quoted 4 lines
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
Marcel Holtmann
maintainerHi Brad,
Quoted 7 lines
Quoted 6 lines
Quoted 3 lines
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.
Quoted 7 lines
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.
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
void
PressHeadsetButton()Indicate a button press to the connected audio gateway.
Quoted 7 lines
Quoted 1 line
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
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
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
Brad
Quoted 2 lines
in progress. I'd much rather have
Answered()andPlaying()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
Quoted 8 lines
Quoted 5 lines
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
Quoted 7 lines
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
Fabien
Quoted 2 lines
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
Hi Marcel & Brad, please find a few questions below:
Quoted 6 lines
Hi Brad,
Quoted 2 lines
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
Quoted 4 lines
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).
Quoted 52 lines
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.
Quoted 47 lines
Audio hierarchy (experimental)
==============================Service org.bluez
Interface org.bluez.AudioMethods 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 ?
Quoted 23 lines
Timeouts must be in uint32 and name them "timeout". Delay would be used in case a process is sent to sleep.
Quoted 5 lines
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.
Quoted 3 lines
void
ChangeVolume(string identifier, string profile, int16 delta)delta is +1 or -1
No. Use IncreaseVolume and DecreaseVolume.
Quoted 4 lines
void
AddWiredVoice()Add wired audio output to the voice routing rule
Quoted 8 lines
Quoted 4 lines
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
Fabien
Quoted 5 lines
Quoted 1 line
Quoted 1 line
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.
Quoted 3 lines
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
Hi Brad,
Quoted 11 lines
Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
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
Quoted 7 lines
Quoted 4 lines
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
Fabien
Quoted 11 lines
Quoted 9 lines
Quoted 4 lines
Quoted 1 line
Quoted 1 line
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.
Quoted 8 lines
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
Quoted 8 lines
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,
Quoted 9 lines
Quoted 3 lines
Quoted 2 lines
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
Quoted 1 line
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
Quoted 9 lines · Brad Midgley
Fabien
Quoted 1 line
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.
Quoted 4 lines
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