[PATCH 1/4] add the D-Bus interface definition for HFP Audio gateway -- take4 -- rebased

[PATCH 1/4] add the D-Bus interface definition for HFP Audio gateway -- take4 -- rebased

[Forrest]

---
 doc/audio-api.txt |  114 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 114 insertions(+), 0 deletions(-)

diff --git a/doc/audio-api.txt b/doc/audio-api.txt
index 7e8492d..7eea7ca 100644
--- a/doc/audio-api.txt
+++ b/doc/audio-api.txt
@@ -289,3 +289,117 @@ properties	string State [readonly]
 
 			Indicates if a stream is active to a A2DP sink on
 			the remote device.
+
+
+Gateway hierarchy
+===================
+
+Service		org.bluez
+Interface	org.bluez.HeadsetGateway
+Object path	[variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
+
+This interface is available for remote devices which can function in the Audio
+Gateway role of the HFP profiles.
+
+Methods		void Connect()
+
+			Connect to the AG service on the remote device.
+
+		void Disconnect()
+
+			Disconnect from the AG service on the remote device
+
+		void AnswerCall()
+
+			It has to called only after Ring signal received.
+
+		void TerminateCall()
+
+			Terminate call which is running or reject an incoming
+			call. This has nothing with any 3-way situation incl.
+			RaH. Just plain old PDH.
+
+		void Call(string number)
+
+			Dial a number 'number'. No number processing is done
+			thus if AG would reject to dial it don't blame me :)
+
+		string GetOperatorName()
+
+			Find out the name of the currently selected network
+			operator by AG.
+
+		void SendDTMF(string digits)
+
+			Will send each digit in the 'digits' sequentially. Would
+			send nothing if there is non-dtmf digit.
+
+		string GetSubscriberNumber()
+
+			Get the voicecall subscriber number of AG
+
+		dict GetProperties()
+
+			Returns all properties for the interface. See the
+			properties section for available properties.
+
+Signals		void Ring(string number)
+
+			Someone's calling from 'number'.
+			Caller number is provided as received from AG.
+
+		void CallTerminated()
+
+			Call failed to set up. It means that we tried to call
+			someone or someone tried to call us but call was not
+			accepted.
+
+		void CallStarted()
+
+			Call set up successfully.
+
+		void CallEnded()
+
+			Call was started and now ended. In contrast with
+			CallTerminated where call didn't started
+
+		PropertyChanged(string name, variant value)
+
+			This signal indicates a changed value of the given
+			property.
+
+properties	boolean Connected [readonly]
+
+			Indicates if there is an active connection to the
+			AG service on the remote device.
+
+		uint16 RegistrationStatus [readonly]
+
+			Service availability indicatior of AG, where:
+			0 implies no service. No Home/Roam network available.
+			1 implies presense of service. Home/Roam network
+			  available.
+
+		uint16 SignalStrength [readonly]
+
+			Signal strength indicator of AG, the value ranges from
+			0 to 5.
+
+		uint16 RoamingStatus [readonly]
+
+			Roaming status indicator of AG, where:
+			0 means roaming is not active
+			1 means a roaming is active
+
+		uint16 BatteryCharge [readonly]
+
+			Battery Charge indicator of AG, the value ranges from
+			0 to 5.
+
+		uint16 SpeakerGain  [readonly]
+
+			The speaker gain when available.
+
+		uint16 MicrophoneGain  [readonly]
+
+			The speaker gain when available.
-- 
1.5.4.5

Re: [PATCH 1/4] add the D-Bus interface definition for HFP Audio gateway -- take4 -- rebased

[Johan Hedberg]

Hi Forrest,

The first three patches have been pushed upstream with some minor modifications
(compilation warning fixes and disabling the new feature by default). However,
the fourth one which binds it all to the IPC needs some rethinking. Right now
it'd break backwards compatibility for the IPC which we'd like to avoid since
we juts did that for 4.34. Also, there are some added terms like master and
slave (used for HFP/A2DP roles) which should be renamed to something more
intuitive (assuming they need to be in the IPC at all).

Johan

Re: [PATCH 1/4] add the D-Bus interface definition for HFP Audio gateway -- take4 -- rebased

[Zhao Forrest]

> The first three patches have been pushed upstream with some minor modifications
> (compilation warning fixes and disabling the new feature by default). However,
> the fourth one which binds it all to the IPC needs some rethinking. Right now
> it'd break backwards compatibility for the IPC which we'd like to avoid since
> we juts did that for 4.34. Also, there are some added terms like master and
> slave (used for HFP/A2DP roles) which should be renamed to something more
> intuitive (assuming they need to be in the IPC at all).

Thank you for your comments. I'll revise the IPC part ASAP after coming back
from the Chinese Qingming holiday.

Thanks,
Forrest

patch to fix a2dp issue

[Xu, Martin]

Hi:
We have found a2dp issue, that bluez earphone can not work. The issue has filed at: 
https://bugzilla.moblin.org/show_bug.cgi?id=1355 
(Some one can kindly tell me where I can file the bluez bug. So I can transfer the bug from moblin bugzilla there.)

The root cause is that:
bluez-alsa-plugin has issue at poll revents.
alsa lib needs to poll 2 channel state. But bluez-alsa-plugin only handles
channel1 revent, and leave another one unhandled which leads to the channel's
poll state unpredictable, consequently, pcm stream transfer is broken for the
wront poll state, and bluethooh earphone(a2dp) can not work.
I have worked out a patch to fix the issue, which is listed as below. 
BTW: 
I found the issue at bluez-4.30 but I find that the latest bluez git tree still has the issue.
I just touch bluez, if something not accurate, please let me know. ;)

diff --git a/audio/pcm_bluetooth.c b/audio/pcm_bluetooth.c
index 9bef89e..1af07b3 100644
--- a/audio/pcm_bluetooth.c
+++ b/audio/pcm_bluetooth.c
@@ -798,7 +798,7 @@ static int bluetooth_playback_poll_revents(snd_pcm_ioplug_t *io,
 		io->state = SND_PCM_STATE_DISCONNECTED;
 
 	*revents = (pfds[0].revents & POLLIN) ? POLLOUT : 0;
-
+	*(revents+1) = (pfds[1].revents & POLLIN) ? POLLOUT : 0;
 	return 0;
 }

Re: patch to fix a2dp issue

[Johan Hedberg]

Hi,

On Tue, Apr 07, 2009, Xu, Martin wrote:
> We have found a2dp issue, that bluez earphone can not work. The issue has
> filed at: https://bugzilla.moblin.org/show_bug.cgi?id=1355
> (Some one can kindly tell me where I can file the bluez bug. So I can
> transfer the bug from moblin bugzilla there.)

There's no bluez "bugzilla". The email you sent to this list should be good
enough.

> The root cause is that:
> bluez-alsa-plugin has issue at poll revents.
> alsa lib needs to poll 2 channel state. But bluez-alsa-plugin only handles
> channel1 revent, and leave another one unhandled which leads to the channel's
> poll state unpredictable, consequently, pcm stream transfer is broken for the
> wront poll state, and bluethooh earphone(a2dp) can not work.
> I have worked out a patch to fix the issue, which is listed as below.

This is a well known issue with all bluez versions after 4.27. It has been
discussed several times on the #bluez channel as well as the alsa-devel mailing
list [1]. It's caused by commit 593bd41ed861d80f498fa8cfe0cea06e0c11f442 (which
btw also has a link to the alsa-devel thread) and unfortunately it seems we
cannot revert it. The conclusion from the alsa side was that the correct
behavior for applications is to always pass just one filedescriptor in revents
and so if we try to read revents[1] we'd be accessing invalid memory with
applications that use the API correctly.

Johan

[1] http://mailman.alsa-project.org/pipermail/alsa-devel/2009-February/014392.html

RE: patch to fix a2dp issue

[Xu, Martin]

Thanks for your response.
But we can not always leave the a2dp feature as broken. I used the latest aplay application which is from alsa project(alsa-utils) to test the a2dp feature. That shows the application part, at least ALSA part is not fixed.
In my opinions, if the effort is not big, can we fix it at bluez alsa plugin? At least, it is the alsa plugin and it should comply with the interface although the interface keeps changing.:)

Re: patch to fix a2dp issue

[Marcel Holtmann]

Hi Martin,

> But we can not always leave the a2dp feature as broken. I used the  
> latest aplay application which is from alsa project(alsa-utils) to  
> test the a2dp feature. That shows the application part, at least  
> ALSA part is not fixed.
> In my opinions, if the effort is not big, can we fix it at bluez  
> alsa plugin? At least, it is the alsa plugin and it should comply  
> with the interface although the interface keeps changing.:)

we can NOT fix it on the BlueZ side. Please do read the discussion  
about it since it has been discussed in length. It is an ALSA API  
issue and needs to be fixed within the applications using ALSA.

Regards

Marcel