[pulseaudio-discuss] Bluetooth devices no longer detected after upgrade from 2.0 to 4.0

[Georg Chini]

Hi Mikel,

On 26.06.2013 16:54, Mikel Astiz wrote:
> Hi Georg,
>
> On Wed, Jun 26, 2013 at 3:27 PM, Georg Chini <georg at chini.tk> wrote:
>> Hi Mikel,
>>
>>
>> On 24.06.2013 11:22, Mikel Astiz wrote:
>>> This seems a successful connection of HSP/HFP. The module is however not
>>> loaded because the overall connection procedure (org.bluez.Audio) is still
>>> ongoing, and therefore the load of the module is postponed.
>>>> D: [lt-pulseaudio] bluetooth-util.c: dbus:
>>>> interface=org.bluez.MediaEndpoint, path=/MediaEndpoint/HFPAG,
>>>> member=SetConfiguration
>>>> D: [lt-pulseaudio] module-console-kit.c: dbus:
>>>> interface=org.bluez.MediaEndpoint, path=/MediaEndpoint/HFPAG,
>>>> member=SetConfiguration
>>>> D: [lt-pulseaudio] bluetooth-util.c: dbus: path=/MediaEndpoint/HFPAG,
>>>> interface=org.bluez.MediaEndpoint, member=SetConfiguration
>>>> E: [lt-pulseaudio] bluetooth-util.c: Cannot configure transport
>>>> /org/bluez/7417/hci1/dev_00_19_7F_41_DB_2E/fd41 because profile 2 is
>>>> already
>>>> used
>>> You hit the first issue here. It looks to me that BlueZ is starting
>>> the connection procedure twice, for the same profile, using a
>>> different transport.
>>>
>>> This looks like a bug in BlueZ. Any chance you can upgrade to 4.101?
>>>
>>> I've had a look at the commits between 4.99 and 4.101 and there seem
>>> to be a bunch of fixes which could be related to this issue.
>>>
>>>
>> Thanks a lot. You were right here. Upgrading to bluez 4.101 solved this
>> problem. But now I have another one:
>>
>> For pulseaudio 2 I wrote a python application which is basically a more
>> comfortable version of module-bluetooth-policy. It makes it easy to use
>> your mobile from your desktop. It lets you direct the sound to a sound card
>> of your choice (which may be different for a2dpsource and HFP gateway),
>> change it on the fly and switch echo cancellation on and off. With the help
>> of ofono you can also accept calls or make calls from your desktop.
> I believe you could implement similar policies within pulseaudio
> without the need of additional scripts, but anyway...
Maybe. But when I started using pulse a few month ago I could not
figure out how.
>
>> When I started programming I inserted loopback modules each time the mobile
>> changed state to "playing" and unloaded them when the phone went back to
>> "connected".
>> (In pulseaudio 2 the profile was then set to "off", so source and sink were
>> no longer
>> available)
> module-bluetooth-policy will take care of switching between profiles
> automatically. If you're not interested in the module-loopback part,
> then you might want to load module-bluetooth-policy with the arguments
> hfgw=0 a2dp_source=0.
Thanks for the hint. I was under the impression that the module does
nothing when you set both parameters to 0.
>> Later on I decided to keep the modules around and just move them to the
>> right
>> source/sink when needed and move them to the default sound card and mute
>> them when not in use.
> As a side suggestion, you probably want to use the profile
> availability to do this (if profile is available, it means 'playing').
>
>> The problem is that this does no longer work. Pavucontrol still shows the
>> correct
>> sink/source but I do not get any sound when the modules are reused. It seems
>> to be
>> a problem of resampling, the modules start to behave strangely as soon as
>> sink and
>> source are moved the first time.
>> In the debug output I get endless repetition of:
>>
>> [alsa-sink-VT1828S Analog] module-loopback.c: Could not peek into queue
>> [alsa-sink-VT1828S Analog] module-loopback.c: Requesting rewind due to end
>> of underrun.
>> [alsa-sink-VT1828S Analog] module-loopback.c: Requesting rewind due to end
>> of underrun.
>> [alsa-sink-VT1828S Analog] module-loopback.c: Requesting rewind due to end
>> of underrun.
>> [alsa-sink-VT1828S Analog] module-loopback.c: Requesting rewind due to end
>> of underrun.
>>
>> The initial approach of using fresh modules each time the phone goes to
>> "playing" still
>> works fine.
> I think you hit a real issue here. I've experienced similar issues too
> at some point, but I can't reproduce it anymore.
>
> Can you tell us which exact states the source (assuming A2DP from the
> phone) and the source-output have? They should in theory be both in
> RUNNING state.
Sorry, I cannot find out. You can find a log of a complete session on
http://philipp.chini.tk/pulse/pulse-session.log
Maybe there is something useful in it. If not, please tell me how to get
the state of the source or what else I can do to locate the problem.

>> Any ideas what might cause this? Again any help or hint is welcome.
>>
>> Regards
>>               Georg
> Cheers,
> Mikel
Thanks a lot for your help so far.

Regards
              Georg