On Tue, Feb 2, 2010 at 01:50, Zhenhua Zhang <zhenhua.zhang(a)intel.com> wrote:
On 02/02/2010 01:09 AM, João Paulo Rechi Vita wrote:
> 2010/1/29 João Paulo Rechi Vita<jprvita(a)gmail.com>:
>> Hi all,
>> I'm trying to add support for the Handsfree Gateway role Gustavo just
>> to BlueZ and oFono. The BlueZ patches can be found on  and  and the
>> oFono part was just merged upstream.
>> But when it comes to integrate them with Pulse, I'm getting a POLLHUP
>> trying to write on the fd. Also, it seems different gateways have
>> behaviours regarding when they connect the SCO link. Some phone connect
>> them just after the RFCOMM link (some Nokia phones), when there is no
>> 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
>> 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.
>>  http://www.spinics.net/lists/linux-bluetooth/msg04250.html
>>  http://www.spinics.net/lists/linux-bluetooth/msg04251.html
>> João Paulo Rechi Vita
> 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.
The output from bluetoothd likes below:
bluetoothd: Accepted AG connection from 00:BD:3A:D4:4E:53 for
bluetoothd: Accepted SCO connection from 00:BD:3A:D4:4E:53
bluetoothd: No matching connection found for handle 6
bluetoothd: sco connection is released
I think you should not load module-bluetooth-device until a voice call is
started, no matter incoming or outgoing. Because PA may play music from
other device at the same time. And bluetooth-device and loopback module are
loaded together. According to HFP v1.5 4.13, there are two cases for
incoming call. And outgoing call is simpler than incoming call.
If AG and HF both support in band ring tones, we should send a signal from
oFono to PA when callsetup=1. If not, we should send it when call=1.
I had a patch originally but I cannot find it now. :-(. The basic idea is to
add a filter in ciev_notify() to emit signal (CallStarted and CallEnded) to
PA. And PA loads module once it got that signal. Maybe the signal name was
bad and you could choose better one as you want. ;-)
I think loading module-bluetooth-device only when there is an active
call can be a good solution. But I'm concerned about other audio
events, i. e.: ringing, SMS notification etc.: doesn't the AG
establishes a SCO channel for the these events? Also, I don't think
pulse should listen to ofono signals, it should be agent-agnostic. But
a signal could be added to the agent interface in this case.
And I'm not sure if automatically loading module-loopback is a good
idea, I think we better expose through the UI how to handle the audio
stream. Some users may have a bunch of soundcards or some very weird
audio setup, and it's up to them to decide which soundcard to connect
the HFP stream.
João Paulo Rechi Vita