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
