[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 8:45 PM, Georg Chini <georg at chini.tk> wrote:
> 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.

You should use 'pactl list sources' and 'pactl list source-outputs',
during the issue you describe about rewind requests.

Cheers,
Mikel