Hello Luiz, Johan, Marcel! (cc'ing pulseaudio-discuss for awareness, but I believe nothing is wrong on PulseAudio side) I'm investigating a problem on to the interaction of more than one PulseAudio instance with bluetoothd, specifically when registering the HSP external profiles (oFono is not being used). On my setup, one PulseAudio instance is started for GDM, and when the user logs in, another instance is started for the user session. A few moments later the GDM session finishes and the first PulseAudio instance exits. The first instance is able to register support for HSP AG just fine, and a SDP record is added to the server. When the second instance starts, while the first one is already active, the RFCOMM server fails to bind the socket, but the profile probe does not fail. From PulseAudio's perspective everything worked just fine, but a SDP record is not added to the server. This does not have any symptoms at this point, since the record from the first instance is still active. You can find the logs when that happens bellow. Aug 29 20:03:40 mimieux pulseaudio[3166]: D: [pulseaudio] backend-native.c: Bluetooth Headset Backend API support using the native backend Aug 29 20:03:40 mimieux pulseaudio[3166]: D: [pulseaudio] backend-native.c: Registering Profile /Profile/HSPAGProfile 00001112-0000-1000-8000-00805f9b34fb Aug 29 20:03:40 mimieux pulseaudio[3166]: I: [pulseaudio] backend-ofono.c: Failed to register as a handsfree audio agent with ofono: org.freedesktop.DBus.Error.ServiceUnknown: The name org.ofono was not provided by any .service files Aug 29 20:03:40 mimieux pulseaudio[3166]: D: [pulseaudio] bluez5-util.c: oFono is running: no Aug 29 20:03:40 mimieux bluetoothd[796]: src/profile.c:register_profile() sender :1.864 Aug 29 20:03:40 mimieux bluetoothd[796]: src/profile.c:create_ext() Created "Headset Voice gateway" Aug 29 20:03:40 mimieux bluetoothd[796]: src/profile.c:ext_adapter_probe() "Headset Voice gateway" probed Aug 29 20:03:40 mimieux bluetoothd[796]: RFCOMM server failed for Headset Voice gateway: rfcomm_bind: Address already in use (98) Aug 29 20:03:40 mimieux bluetoothd[796]: src/profile.c:ext_device_probe() Headset Voice gateway probed with UUID 00001108-0000-1000-8000-00805f9b34fb Aug 29 20:03:40 mimieux bluetoothd[796]: src/service.c:change_state() 0x556fa9e9f470: device 00:16:94:0B:1B:8B profile Headset Voice gateway state changed: unavailable -> disconnected (0) The problem happens when the first instance finally exits, and its SDP record is removed. At this point there is a valid agent for the profile (the second PulseAudio instance), but its UUID is not in list of supported UUIDs on the SDP server for that adapter, and not on the UUIDs property on the adapter object on D-Bus either. While pairing and re-connections to headsets seem to be working fine even after that failure, this is causing problems with a downstream change we carry on PulseAudio at Endless, where we look at the supported UUIDs from both the adapter and the device to device whether a certain profile is supported, and then only create card profiles for supported Bluetooth profiles. So in this case we end up without a card profile for HSP even though the profile is actually supported. This change is pending upstream review on https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/50, but in any case the SDP database and UUIDs property should be consistent with the list of supported profiles. I'm not familiar with BlueZ' RFCOMM implementation, and haven't really touched on BlueZ' code in a while, so I don't know what is the right fix for this problem. I can write patches if given a general direction of how to approach it, but I'm happy to test someone else's patches as well. Thanks! -- João Paulo Rechi Vita
