The 5.0 BlueZ

Posted Jan 7, 2013 22:03 UTC (Mon) by dlang (guest, #313)
In reply to: The 5.0 BlueZ by n8willis
Parent article: The 5.0 BlueZ

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.