On 17.10.2014 12:37, Tanu Kaskinen wrote:
> On Mon, 2014-10-13 at 22:34 +0200, Georg Chini wrote:
>> 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
> Could you file a bug? I think this should be investigated before the
> next release, but I don't have time for that right now.
ok, will do.
>>>> 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.
> What D-Bus signals do you mean? Typically applications don't use D-Bus
> to communicate with PulseAudio. Getting notifications about profile
> changes in PulseAudio can be done with the subscription API in libpulse.
>
Bluez4 provided D-Bus signals on profile changes and I used them as
notification. But thanks for the hint - if there is another way to get
notified
by PulseAudio that is fine for me.
Regards
Georg
