The 5.0 BlueZ

Posted Jan 7, 2013 21:21 UTC (Mon) by n8willis (subscriber, #43041)
In reply to: The 5.0 BlueZ by dlang
Parent article: The 5.0 BlueZ

Perhaps I'm misunderstanding you, but I think it's the other way around: when the GStreamer code for a profile was in BlueZ, it created a dependency. When it's pushed out to GStreamer, you can install and run BlueZ without it, and any other implementation of the same profile (in JACK, let's say) would work too, via BlueZ's generic Profile API.

Nate

The 5.0 BlueZ

Posted Jan 7, 2013 22:03 UTC (Mon) by dlang (guest, #313) [Link] (1 responses)

It seems to me that if the profile is managed in BlueZ, then any app can talk to BlueZ and use that profile

But if the profile is moved out of BlueZ and into GStreamer, then any other app that wants to use that profile now needs to duplicate (or re-write if there are licensing incompatibilities) the code for the profile.

If I am understanding this correctly, this is moving what software implements the abstraction layer, instead of BlueZ implementing the abstraction layer and offering a standard service to all other apps on the system, BlueZ is now exposing only the lower level functionality and each and every app needs to implement the abstraction layer (i.e. the profile)

The 5.0 BlueZ

Posted Jan 8, 2013 16:40 UTC (Tue) by jh (guest, #17427) [Link]

It'd probably help if we discussed this in a bit more specific terms since I'm not sure if you're referring to the GStreamer elements or what regarding the "outsourcing" of profiles.

Anyway, for the GStreamer elements, there was always a dependency on the GStreamer library to compile these while they were within BlueZ. With BlueZ 5 the dependency is no longer there. That said, this particular example isn't really that valuable since the GStreamer elements were never used for much else than testing. A typical distro would use something else like PulseAudio for properly working A2DP and from that perspective there really isn't much change going from BlueZ 4 to 5.