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
