Return-Path: Message-ID: <4B678217.6050003@intel.com> Date: Tue, 02 Feb 2010 09:38:31 +0800 From: Zhenhua Zhang MIME-Version: 1.0 To: "ofono@ofono.org" , =?UTF-8?B?Sm/Do28gUGF1bG8gUmVjaGk=?= =?UTF-8?B?IFZpdGE=?= CC: "pulseaudio-discuss@mail.0pointer.de" , "Zheng, Huan" , "linux-bluetooth@vger.kernel.org" , Lennart Poettering Subject: Re: [RFC] [PATCH 0/2] HFP AG integration with PulseAudio References: <1264776266-7646-1-git-send-email-jprvita@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Sender: linux-bluetooth-owner@vger.kernel.org List-ID: Hi Jprvita, On 02/02/2010 01:09 AM, João Paulo Rechi Vita wrote: > 2010/1/29 João Paulo Rechi Vita: > >> 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.