Hi David, On Wed, May 22, 2013 at 12:00 PM, David Henningsson <david.henningsson at canonical.com> wrote: > On 05/21/2013 05:18 PM, Mikel Astiz wrote: >> >> Hi David, >> >> On Tue, May 21, 2013 at 3:55 PM, David Henningsson >> <david.henningsson at canonical.com> wrote: >>> >>> On 05/21/2013 02:58 PM, Mikel Astiz wrote: >>>> >>>> >>>> Hi David, >>>> >>>> On Tue, May 21, 2013 at 2:37 PM, David Henningsson >>>> <david.henningsson at canonical.com> wrote: >>>>> >>>>> >>>>> On 05/20/2013 11:48 AM, Mikel Astiz wrote: >>>>>> >>>>>> >>>>>> >>>>>> From: Mikel Astiz <mikel.astiz at bmw-carit.de> >>>>>> >>>>>> These patches address a regression existing in the master branch, >>>>>> which >>>>>> specially affects the gnome UI. More info in >>>>>> https://bugs.freedesktop.org/show_bug.cgi?id=64713. >>>>> >>>>> >>>>> >>>>> >>>>> Thanks, I have now tested them and confirmed that they solve the >>>>> problem >>>>> here! >>>>> >>>>> >>>>>> The proposed solution is fairly simple but triggers the question >>>>>> whether >>>>>> something like PA_CORE_HOOK_PORT_PROFILE_ADDED is needed in the case >>>>>> of >>>>>> late >>>>>> Bluetooth UUIDs. In this scenario, the port has already been created >>>>>> by >>>>>> the >>>>>> time a new profile needs to be registered, typically after a >>>>>> Bluetooth-pairing procedure (for reference, see >>>>>> d4368aa608b79f58a279018eb74abd5a6bff30ac). >>>>> >>>>> >>>>> >>>>> >>>>> I'm not really familiar with the late UUID problem, how common is that >>>>> really? I have never seen it myself, but then my range of hardware is >>>>> limited to a simple headset and a laptop. >>>> >>>> >>>> >>>> It's fairly common when pairing phones but I've never seen it with >>>> headsets. In practice, I'd say it's hardly possible to hit this issue >>>> when the pairing procedure (the Bluetooth device discovery) is >>>> initiated from our side, which is the case for all headsets. >>>> >>>> Besides, obviously, it's only possible with devices that support >>>> multiple profiles (HSP/HFP + A2DP). >>> >>> >>> >>> Actually, I have a phone running Android 4.0 here, so I tried pairing it >>> with the laptop from the phone side, but there was no bluetooth card >>> showing >>> up at all on the laptop side, and all in the gnome bluetooth GUI is a >>> checkbox asking me for network connections. >>> >>> Maybe Android 4.0 (or my version of bluez?) does not support relaying >>> audio >>> to (or from?) the phone? >> >> >> This should be working assuming BlueZ is configured properly. You >> might need to configure BlueZ's audio.conf with: >> >> Enable=Media,Headset,Gateway,Sink,Source >> >> This might not be necessary if your BlueZ is patched which is probably the >> case. > > > If this was not the case, there should not have been an AudioSource.Connect > method at all, right? Correct. > >> Another possible issue is that you never connected the profiles. You >> can try by calling the D-Bus AudioSource.Connect() (for A2DP) or > > > When I do this, my phone lights up, > the following is added to syslog, > "bluetoothd[1066]: Connection refused (111)" > and the call, after some time, returns > "GDBus.Error:org.bluez.Error.Failed: Stream Setup Failed" This is weird. Any chance you might have overlooked a confirmation UI on the phone? Some phones prompt the user for incoming connections, but this is nowadays less common. > >> HandsfreeGateway.Connect() (for HFP). > > > This returns > "GDBus.Error:org.bluez.Error.AgentNotAvailable: Agent Not Available". This is because you're not running oFono, where this role of HFP is implemented. > >> This is likely if the phone >> didn't initiate the connection automatically after pairing. You can >> also play around by manually initiating the connection on the phone's >> UI. > > > I can't do much in the UI (Samsung). The two checkboxes saying something > like "Use for phone sound" and "Use for media sound" are both checked. This would be the first phone I know of that doesn't have a UI to initiate connections to a headset (in this case, your laptop). Cheers, Mikel
