On 13.10.2014 16:09, Luiz Augusto von Dentz wrote:
> Hi,
>
> On Sat, Oct 11, 2014 at 10:32 PM, Georg Chini <georg at chini.tk> wrote:
>> Hello,
>>
>> I just pulled a current GIT and installed it. I find two issues with the
>> ofono backend:
>>
>> 1) When I connect my headset the device does not vanish
>> when I disconnect it. pactl list cards still shows
>> card #4
>> Name: bluez_card.00_19_7F_41_DB_2E
>> Treiber: module-bluez5-device.c
>> Owner-Modul: 28
>> Eigenschaften:
>> device.description = "590Plantronics"
>> device.string = "00:19:7F:41:DB:2E"
>> device.api = "bluez"
>> device.class = "sound"
>> device.bus = "bluetooth"
>> device.form_factor = "headset"
>> bluez.path = "/org/bluez/hci1/dev_00_19_7F_41_DB_2E"
>> bluez.class = "0x240404"
>> bluez.alias = "590Plantronics"
>> device.icon_name = "audio-headset-bluetooth"
>> device.intended_roles = "phone"
>> Profile:
>> headset_head_unit: Headset Head Unit (HSP/HFP) (sinks: 1,
>> sources: 1, priority: 20, available: no)
>> a2dp_sink: High Fidelity Playback (A2DP Sink) (sinks: 1,
>> sources: 0, priority: 10, available: yes)
>> off: Aus (sinks: 0, sources: 0, priority: 0, available: yes)
>> Aktive Profile: off
>> Profile:
>> headset-output: Headset (priority: 0, latency offset: 0
>> usec)
>> Part of profile(s): headset_head_unit, a2dp_sink
>> headset-input: Headset (priority: 0, latency offset: 0 usec,
>> not available)
>> Part of profile(s): headset_head_unit
>>
>> I cannot re-connect the headset before I restart pulse.
>> With my phone there is no such problem, the device appears
>> and disappears as expected.
> That should never happen, are you sure it disconnected? a2dp_sink
> still shows as available which indicates you are still connected.
Yes, I am sure it was disconnected, tried it a couple of times.
Don't have the same issue with the original ofono patches.
If I try to switch profile in that state, pulse crashes (which is
probably expected).
>
>> 2) When I connect my phone and use it, the profile switches to
>> HFP and if it's no longer in use the profile switches to off after
>> a timeout (this was not the case with the initial ofono patches).
>> This is the same as with Bluez4. The problem is, that with Bluez5
>> there is no D-Bus signal which indicates the profile switch. If you
>> have loopback modules connected to phone input/output, they
>> will fall back to the default source/sink without giving the software
>> a chance to react to this.
> Hmm, if you maintain the loopbacks externally that would be a problem
That is exactly my problem. I do not use module-bluetooth-policy
so the software has to know when the profile changes. There is
no Dbus-signal at all, so I would have to poll the availability of the
port. Another problem is that at the moment the loopback modules
fall back to their defaults I get lots of feedback because the microphone
is looped back to the speakers.
> but I guess you can watch for port availability, I tested it with
> module-bluetooth-policy this seems to be working fine perhaps because
> we do set a specific source/sink so once they are destroyed the
> loopbacks are also unloaded.
Yes, with module-bluetooth-policy the loopback modules are unloaded
when the profile changes to off. In my setup I would normally just mute
or unmute them instead of unloading/reloading.
Regards
Georg
