[pulseaudio-discuss] Is it OK for PulseAudio to crash when BlueZ is buggy?

[Tanu Kaskinen]

On Thu, 2012-05-24 at 11:29 +0300, Luiz Augusto von Dentz wrote:
> Hi Tanu,
> 
> On Wed, May 23, 2012 at 4:11 PM, Tanu Kaskinen <tanu.kaskinen at digia.com> wrote:
> > On Wed, 2012-05-23 at 12:20 +0300, Luiz Augusto von Dentz wrote:
> >> Btw, are you sure this is a problem? We can have the same address in
> >> different devices if they are paired with different adapters,
> >> otherwise it is a bug and we should be able to fix it.
> >
> > Thanks for the information. I had the assumption[1] that the device
> > addresses should be unique, but if they're not, the code that I've
> > written is certainly broken.
> >
> > [1] I tried to verify my assumption first by asking on the #bluez irc
> > channel, and after getting no responses, I checked the bluetoothd code
> > and it seemed like the addresses would be guaranteed to be unique. The
> > device objects were put in a map with the address as the key, so there
> > could be no duplicates, but I guess I missed the fact that there are
> > multiple of those maps, one for each adapter.
> 
> The object path is guaranteed to be unique if you need something as a
> hash table key or something like that use it instead of the address,
> but note that object path might change over time due to reboot or
> bluetoothd being restarted, so you need to cleanup.

Yep, I know that. The device address is used for implementing the
"address" module argument for module-bluetooth-device, and that requires
a way to look up a device by its address. Currently that lookup is done
by linearly iterating through the devices and picking the first one that
matches, and I thought that having a hashmap for that lookup would be
nicer, but that has now turned out to be a bad idea.

Otherwise than that use case, I think there's no need to look up devices
by their address - the object path is used instead.

-- 
Tanu