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

[Mikel Astiz]

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...

>
> 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.

> 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.

>
> Any ideas what might cause this? Again any help or hint is welcome.
>
> Regards
>              Georg

Cheers,
Mikel