Re: [pulseaudio-discuss] [RFC] [PATCH 0/2] HFP AG integration with PulseAudio
On Thu, 18.02.10 21:52, João Paulo Rechi Vita (jprv...@gmail.com) wrote: On Wed, Feb 17, 2010 at 01:21, Lennart Poettering lenn...@poettering.net wrote: Is this merged now into Bluez? Or even released? If so I should probably merge your code into our master. Could you publish this on one of your public git trees? Hi Lennart, The code is now completely merged into bluez, so it's time to upstream our side. Patches rebased against master attached. Thanks! Merged! Keep up the great work! Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] [PATCH 0/2] HFP AG integration with PulseAudio
On Wed, Feb 17, 2010 at 01:21, Lennart Poettering
lenn...@poettering.net wrote:
Is this merged now into Bluez? Or even released?
If so I should probably merge your code into our master. Could you
publish this on one of your public git trees?
Hi Lennart,
The code is now completely merged into bluez, so it's time to upstream
our side. Patches rebased against master attached.
--
João Paulo Rechi Vita
http://jprvita.wordpress.com/
From 3a6765de24321ed6654bb81bf17d3db893857690 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Jo=C3=A3o=20Paulo=20Rechi=20Vita?= jprv...@profusion.mobi
Date: Fri, 29 Jan 2010 10:59:33 -0200
Subject: [PATCH 1/2] bluetooth: improve dbus logging
---
src/modules/bluetooth/bluetooth-util.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/modules/bluetooth/bluetooth-util.c b/src/modules/bluetooth/bluetooth-util.c
index b2c0429..7b0e6f8 100644
--- a/src/modules/bluetooth/bluetooth-util.c
+++ b/src/modules/bluetooth/bluetooth-util.c
@@ -293,9 +293,10 @@ static int parse_audio_property(pa_bluetooth_discovery *u, int *state, DBusMessa
const char *value;
dbus_message_iter_get_basic(variant_i, value);
-if (pa_streq(key, State))
+if (pa_streq(key, State)) {
*state = pa_bt_audio_state_from_string(value);
-/* pa_log_debug(Value %s, value); */
+pa_log_debug(dbus: property 'State' changed to value '%s', value);
+}
break;
}
--
1.6.3.3
From 7b72c6fd611069cd65e790c9d8baea268ade9531 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Jo=C3=A3o=20Paulo=20Rechi=20Vita?= jprv...@profusion.mobi
Date: Fri, 29 Jan 2010 11:01:31 -0200
Subject: [PATCH 2/2] bluetooth: add HFP Gateway support
Create the 'Handsfree Gateway' profile for bluetooth cards and add
filters for 'org.bluez.HandsfreeGateway' to the discover module so
module-bluetooth-device is loaded with the correct profile when a
Handsfree Gateway connects to bluetoothd (in this case bluetoothd
is acting as the headset).
---
src/modules/bluetooth/bluetooth-util.c| 30 ++--
src/modules/bluetooth/bluetooth-util.h|3 +
src/modules/bluetooth/module-bluetooth-device.c | 50 +++-
src/modules/bluetooth/module-bluetooth-discover.c |9 +++-
4 files changed, 72 insertions(+), 20 deletions(-)
diff --git a/src/modules/bluetooth/bluetooth-util.c b/src/modules/bluetooth/bluetooth-util.c
index 7b0e6f8..c3b08ea 100644
--- a/src/modules/bluetooth/bluetooth-util.c
+++ b/src/modules/bluetooth/bluetooth-util.c
@@ -98,6 +98,7 @@ static pa_bluetooth_device* device_new(const char *path) {
d-audio_sink_state = PA_BT_AUDIO_STATE_INVALID;
d-audio_source_state = PA_BT_AUDIO_STATE_INVALID;
d-headset_state = PA_BT_AUDIO_STATE_INVALID;
+d-hfgw_state = PA_BT_AUDIO_STATE_INVALID;
return d;
}
@@ -123,11 +124,11 @@ static pa_bool_t device_is_audio(pa_bluetooth_device *d) {
pa_assert(d);
return
-d-device_info_valid
+d-device_info_valid (d-hfgw_state != PA_BT_AUDIO_STATE_INVALID ||
(d-audio_state != PA_BT_AUDIO_STATE_INVALID
(d-audio_sink_state != PA_BT_AUDIO_STATE_INVALID ||
d-audio_source_state != PA_BT_AUDIO_STATE_INVALID ||
- d-headset_state != PA_BT_AUDIO_STATE_INVALID));
+ d-headset_state != PA_BT_AUDIO_STATE_INVALID)));
}
static int parse_device_property(pa_bluetooth_discovery *y, pa_bluetooth_device *d, DBusMessageIter *i) {
@@ -230,7 +231,10 @@ static int parse_device_property(pa_bluetooth_discovery *y, pa_bluetooth_device
PA_LLIST_PREPEND(pa_bluetooth_uuid, d-uuids, node);
/* Vudentz said the interfaces are here when the UUIDs are announced */
-if (strcasecmp(HSP_HS_UUID, value) == 0 || strcasecmp(HFP_HS_UUID, value) == 0) {
+if (strcasecmp(HSP_AG_UUID, value) == 0 || strcasecmp(HFP_AG_UUID, value) == 0) {
+pa_assert_se(m = dbus_message_new_method_call(org.bluez, d-path, org.bluez.HandsfreeGateway, GetProperties));
+send_and_add_to_pending(y, d, m, get_properties_reply);
+} else if (strcasecmp(HSP_HS_UUID, value) == 0 || strcasecmp(HFP_HS_UUID, value) == 0) {
pa_assert_se(m = dbus_message_new_method_call(org.bluez, d-path, org.bluez.Headset, GetProperties));
send_and_add_to_pending(y, d, m, get_properties_reply);
} else if (strcasecmp(A2DP_SINK_UUID, value) == 0) {
@@ -403,9 +407,14 @@ static void get_properties_reply(DBusPendingCall *pending, void *userdata) {
} else if (dbus_message_has_interface(p-message, org.bluez.AudioSink)) {
if (parse_audio_property(y, d-audio_sink_state, dict_i) 0)
goto finish;
+
} else if (dbus_message_has_interface(p-message,
Re: [pulseaudio-discuss] [RFC] [PATCH 0/2] HFP AG integration with PulseAudio
On Wed, 03.02.10 16:38, João Paulo Rechi Vita (jprv...@gmail.com) wrote: On Tue, Feb 2, 2010 at 09:10, Lennart Poettering lenn...@poettering.net wrote: On Fri, 29.01.10 12:53, João Paulo Rechi Vita (jprv...@gmail.com) wrote: Any help on testing and getting this working together or comments on the topic would be appreciated. [1] http://www.spinics.net/lists/linux-bluetooth/msg04250.html [2] http://www.spinics.net/lists/linux-bluetooth/msg04251.html I forgot to add, suspending of the sink/source seemed to cause disconnection by the AG, so you might want to disable module-suspend-on-idle when testing. BTW, Lennart, is there any way to mark a source/sink to not be suspended? Not really. As Colin mentioned you can make suspending a simple NOOP which does what you want. That said I do believe it makes a lot of sense to actually mark sinks as suspendable. I.e. Introduce a sink flag PA_SINK_SUSPENDABLE or so that we flag for all sinks that actually support suspending and leave unset fo all others, like yours. Even after figuring out suspending wasn't really causing any problem to my tests, it sounds like a good thing to have support for. Anyway, the patches look really good to me. I'd be happy to merge this, though is the bluez counterpart merged yet? (sorry, haven't closely followed bluez development for a while) BlueZ part is still not merged, the code is under peer-review now but it's likely to be merged soon. There may be some modification on which signals to listen in order to load module-bluetooth-device (for HFP case only), also. I'll send a patch rebased against git's head when the merging time comes. Is this merged now into Bluez? Or even released? If so I should probably merge your code into our master. Could you publish this on one of your public git trees? Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] [PATCH 0/2] HFP AG integration with PulseAudio
On Tue, Feb 2, 2010 at 09:10, Lennart Poettering lenn...@poettering.net wrote: On Fri, 29.01.10 12:53, João Paulo Rechi Vita (jprv...@gmail.com) wrote: Any help on testing and getting this working together or comments on the topic would be appreciated. [1] http://www.spinics.net/lists/linux-bluetooth/msg04250.html [2] http://www.spinics.net/lists/linux-bluetooth/msg04251.html I forgot to add, suspending of the sink/source seemed to cause disconnection by the AG, so you might want to disable module-suspend-on-idle when testing. BTW, Lennart, is there any way to mark a source/sink to not be suspended? Not really. As Colin mentioned you can make suspending a simple NOOP which does what you want. That said I do believe it makes a lot of sense to actually mark sinks as suspendable. I.e. Introduce a sink flag PA_SINK_SUSPENDABLE or so that we flag for all sinks that actually support suspending and leave unset fo all others, like yours. Even after figuring out suspending wasn't really causing any problem to my tests, it sounds like a good thing to have support for. Anyway, the patches look really good to me. I'd be happy to merge this, though is the bluez counterpart merged yet? (sorry, haven't closely followed bluez development for a while) BlueZ part is still not merged, the code is under peer-review now but it's likely to be merged soon. There may be some modification on which signals to listen in order to load module-bluetooth-device (for HFP case only), also. I'll send a patch rebased against git's head when the merging time comes. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss -- João Paulo Rechi Vita http://jprvita.wordpress.com/ ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] [PATCH 0/2] HFP AG integration with PulseAudio
On Fri, 29.01.10 12:53, João Paulo Rechi Vita (jprv...@gmail.com) wrote: Any help on testing and getting this working together or comments on the topic would be appreciated. [1] http://www.spinics.net/lists/linux-bluetooth/msg04250.html [2] http://www.spinics.net/lists/linux-bluetooth/msg04251.html I forgot to add, suspending of the sink/source seemed to cause disconnection by the AG, so you might want to disable module-suspend-on-idle when testing. BTW, Lennart, is there any way to mark a source/sink to not be suspended? Not really. As Colin mentioned you can make suspending a simple NOOP which does what you want. That said I do believe it makes a lot of sense to actually mark sinks as suspendable. I.e. Introduce a sink flag PA_SINK_SUSPENDABLE or so that we flag for all sinks that actually support suspending and leave unset fo all others, like yours. Anyway, the patches look really good to me. I'd be happy to merge this, though is the bluez counterpart merged yet? (sorry, haven't closely followed bluez development for a while) Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] [PATCH 0/2] HFP AG integration with PulseAudio
Hi, 2010/1/29 João Paulo Rechi Vita jprv...@gmail.com: Hi all, I'm trying to add support for the Handsfree Gateway role Gustavo just added to BlueZ and oFono. The BlueZ patches can be found on [1] and [2] and the oFono part was just merged upstream. But when it comes to integrate them with Pulse, I'm getting a POLLHUP when trying to write on the fd. Also, it seems different gateways have different behaviours regarding when they connect the SCO link. Some phone connect them just after the RFCOMM link (some Nokia phones), when there is no call going on yet, and others just when a call is started (Android 1.5). Also, right now the same property (State) is beeing used to refer when the RFCOOM link is established (State=Connected) and when the SCO link is established (State=Playing). Shouldn't this be handled by separate props? And last but not least, is the new Media API intended to handle the audio part of handsfree gateways too? If so, maybe we should use all this work as a prototype for latter integration with the new API. Yep, Media API is supposed to handle this, that why I asked them to be though in an integrated manner maybe being registered in the same interface (although hfp is not really media only), anyway basically we should have pa acting as a2dp source/sink and/or hfp gateway/headset endpoint handling the audio. So in essence ofono is acting as a controller/target in a very similar way as avrcp does for a2dp, although for avrcp we don't really need an agent as we use uinput. Any help on testing and getting this working together or comments on the topic would be appreciated. There is already some code in my git tree: http://gitorious.org/~vudentz/bluez/vudentzs-clone/commits/for-upstream -- Luiz Augusto von Dentz Engenheiro de Computação ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] [PATCH 0/2] HFP AG integration with PulseAudio
2010/1/29 João Paulo Rechi Vita jprv...@gmail.com: Hi all, I'm trying to add support for the Handsfree Gateway role Gustavo just added to BlueZ and oFono. The BlueZ patches can be found on [1] and [2] and the oFono part was just merged upstream. But when it comes to integrate them with Pulse, I'm getting a POLLHUP when trying to write on the fd. Also, it seems different gateways have different behaviours regarding when they connect the SCO link. Some phone connect them just after the RFCOMM link (some Nokia phones), when there is no call going on yet, and others just when a call is started (Android 1.5). Also, right now the same property (State) is beeing used to refer when the RFCOOM link is established (State=Connected) and when the SCO link is established (State=Playing). Shouldn't this be handled by separate props? And last but not least, is the new Media API intended to handle the audio part of handsfree gateways too? If so, maybe we should use all this work as a prototype for latter integration with the new API. Any help on testing and getting this working together or comments on the topic would be appreciated. [1] http://www.spinics.net/lists/linux-bluetooth/msg04250.html [2] http://www.spinics.net/lists/linux-bluetooth/msg04251.html -- João Paulo Rechi Vita http://jprvita.wordpress.com/ Just updating, this patch actually worked when testing with a different adapter (Fujitsu-Siemens CSR-based). The adapter causing problems was a Broadcom 2.1, the internal adapter of a Dell Mini10. Also, suspending the source / sink actually doesn't interfere. I did a small video of the whole stuff: http://www.vimeo.com/9078799 There are still some problems when testing against Nokia N900 and 2660. After the enable-modem step, the RFCOMM link is connected and the SCO just after that, leading module-bluetooth-discover to load module-bluetooth-device. Sometimes after that the polling on the stream fd get a POLLHUP and the module-bluetooth-device unloads itself. Other times the POLLHUP doesn't happen and the remaining steps go without any problem. Ideas on how to improve this scenario will be very helpful. -- João Paulo Rechi Vita http://jprvita.wordpress.com/ ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] [PATCH 0/2] HFP AG integration with PulseAudio
Hi Jprvita, On 02/02/2010 01:09 AM, João Paulo Rechi Vita wrote: 2010/1/29 João Paulo Rechi Vitajprv...@gmail.com: Hi all, I'm trying to add support for the Handsfree Gateway role Gustavo just added to BlueZ and oFono. The BlueZ patches can be found on [1] and [2] and the oFono part was just merged upstream. But when it comes to integrate them with Pulse, I'm getting a POLLHUP when trying to write on the fd. Also, it seems different gateways have different behaviours regarding when they connect the SCO link. Some phone connect them just after the RFCOMM link (some Nokia phones), when there is no call going on yet, and others just when a call is started (Android 1.5). Also, right now the same property (State) is beeing used to refer when the RFCOOM link is established (State=Connected) and when the SCO link is established (State=Playing). Shouldn't this be handled by separate props? And last but not least, is the new Media API intended to handle the audio part of handsfree gateways too? If so, maybe we should use all this work as a prototype for latter integration with the new API. Any help on testing and getting this working together or comments on the topic would be appreciated. [1] http://www.spinics.net/lists/linux-bluetooth/msg04250.html [2] http://www.spinics.net/lists/linux-bluetooth/msg04251.html -- João Paulo Rechi Vita http://jprvita.wordpress.com/ Just updating, this patch actually worked when testing with a different adapter (Fujitsu-Siemens CSR-based). The adapter causing problems was a Broadcom 2.1, the internal adapter of a Dell Mini10. Also, suspending the source / sink actually doesn't interfere. I did a small video of the whole stuff: http://www.vimeo.com/907879 Good work! Looks like it works pretty fine. :-). At the last of video, I saw you load loopback module manually. Zheng Huan made a patch to load loopback automatically. I believe Padovan has a copy of that. You may also integrate it with upstream. There are still some problems when testing against Nokia N900 and 2660. After the enable-modem step, the RFCOMM link is connected and the SCO just after that, leading module-bluetooth-discover to load module-bluetooth-device. Sometimes after that the polling on the stream fd get a POLLHUP and the module-bluetooth-device unloads itself. Other times the POLLHUP doesn't happen and the remaining steps go without any problem. Ideas on how to improve this scenario will be very helpful. AFAK, the SCO connection request is from AG side and BlueZ will check if no SCO stream comes from AG(??), it will shutdown the connection. In my memory, I don't get POLLHUP event in my original patch. You can turn on debug flag to see more BlueZ output. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] [PATCH 0/2] HFP AG integration with PulseAudio
2010/1/29 João Paulo Rechi Vita jprv...@gmail.com: Hi all, I'm trying to add support for the Handsfree Gateway role Gustavo just added to BlueZ and oFono. The BlueZ patches can be found on [1] and [2] and the oFono part was just merged upstream. But when it comes to integrate them with Pulse, I'm getting a POLLHUP when trying to write on the fd. Also, it seems different gateways have different behaviours regarding when they connect the SCO link. Some phone connect them just after the RFCOMM link (some Nokia phones), when there is no call going on yet, and others just when a call is started (Android 1.5). Also, right now the same property (State) is beeing used to refer when the RFCOOM link is established (State=Connected) and when the SCO link is established (State=Playing). Shouldn't this be handled by separate props? And last but not least, is the new Media API intended to handle the audio part of handsfree gateways too? If so, maybe we should use all this work as a prototype for latter integration with the new API. Any help on testing and getting this working together or comments on the topic would be appreciated. [1] http://www.spinics.net/lists/linux-bluetooth/msg04250.html [2] http://www.spinics.net/lists/linux-bluetooth/msg04251.html -- João Paulo Rechi Vita http://jprvita.wordpress.com/ I forgot to add, suspending of the sink/source seemed to cause disconnection by the AG, so you might want to disable module-suspend-on-idle when testing. BTW, Lennart, is there any way to mark a source/sink to not be suspended? -- João Paulo Rechi Vita http://jprvita.wordpress.com/ ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] [PATCH 0/2] HFP AG integration with PulseAudio
'Twas brillig, and João Paulo Rechi Vita at 29/01/10 14:53 did gyre and gimble: I forgot to add, suspending of the sink/source seemed to cause disconnection by the AG, so you might want to disable module-suspend-on-idle when testing. BTW, Lennart, is there any way to mark a source/sink to not be suspended? Don't quote me but I think you just handle the sink message PA_SINK_MESSAGE_SET_STATE and make it a noop and don't pass through to calling pa_sink_process_msg(o, code, data, offset, chunk); I catch this message in the raop-sink module but I *do* pass it on to the above function. I could be wrong with the above tho' and there may be a simpler way. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
