0

I am updating Bluez 4.97 to 5.35 in my embedded device.

For A2DP connection, we have to share SBC codec capabilities. In ideal case the capablity will look like figure 1 AVDTP packet with bluez 4.97. In Bluez 4.97 code, I am getting SBC codec capability from sbc_getcap_ind() function in AVDTP layer. In sbc_getcap_ind(), both sbc_codec_cap and avdtp_media_codec_capability are initialized. So this capability packet I can send back to Phone.

In 5.35, sbc_getcap_ind() function is not available. avdtp_media_codec_capability are set in endpoint_getcap_ind() function in AVDTP layer, which is as per my expectation. But sbc_codec_cap is not initialized. So I am getting packect like in figure2AVDTP corrupt packet with bluez 5.35.

In blueZ 5.35 there comes the new package android/hal-audio-sbc.c, in this package SBC coded capability are set.

My embedded device is RTOS based and I have nothing to do with android. So I have following doubt:

1) Why there is new android package in blueZ stack? What's the development idea behind this?

2) Why SBC capabilities are initialized in android/hal-audio-sbc.c, how non-android device will access SBC capabilities?

3) How in my embedded environment, I can use android/hal-audio-sbc.c to get SBC capabilities?

I think I am not able to resolve this issue because I am missing understanding of new 5.35 architecture. And there are not enough documents to understand BlueZ architecture. I hope by getting answer of these question I can understand significance of android folder in 5.35 BlueZ package.

Hari
  • 111
  • 1
  • 1
  • 8

1 Answers1

0

Before answering your questions, I would like to share couple of URL's.

  1. Porting guide
  2. Management interface

Coming for your questions,

  1. BlueZ now supports both android and Linux platform. The directory "android" contains only sources related to android platform, which can't be used for Linux environment. The idea behind this is to share common code of development between Linux and android, and develop common functionalities separately (mostly under "src", "gdbus" and "profile" directories).
  2. As part of BlueZ 4 to BlueZ 5 migration or major development, all the audio related implementations are moved out of BlueZ. Now it's the responsibility of the Audio application to implement the whole stuff on it's own and register with BlueZ (doc/profile-api.txt ==> RegisterProfile() method). BlueZ will only act as the mediator between your application and Devices. As far as Linux is concerned, there is no audio implementation inside BlueZ. Am not sure about Android directory under BlueZ. So non-android platforms needs to implement on it own.
  3. As mentioned, you need to implement our own audio related profiles for BlueZ. We have one working software, which is pulseaudio. You can load the module-bluez-discover in pulseaudio (pactl) and Pulse audio takes care of audio.

There is also another solution available in open source, bluealsa which is currently under active development. After using it, I could see lot of delay in audio and less quality. If you want perfect solution, implement on your own or use pulseaudio (no so much real time).

In simple words, migration application from BlueZ 4.x to BlueZ 5.x is not easy!

Parthiban
  • 2,130
  • 2
  • 14
  • 27
  • In BlueZ 4.x, A2DP is sharing of SBC/MPEG CODEC spec while connection to configure as SOURCE/SINK. Once A2DP connection is established SBC/MPEG audio packet will be sent to L2CAP layer through HCI layer. This SBC/MPEG packet I am sending to personally developed SBC/MPEG decoder. In Bluez 5.x, the SBC/MPEG CODEC specification while A2DP connection is not available, because of which A2DP connection itself failing. So for solution I bought 4.97 SBC get_capablity code to 5.35 and A2DP is connecting and getting SBC packet to L2CAP layer. What you think is it a reliable way in real time scenario? – Hari Apr 12 '17 at 10:25
  • For PulseAudio application, where exactly BlueZ will start communicating with PulseAudio? Whether PulseAudio will fetch audio packets from BlueZ at HCI layer or Transport layer or L2CAP layer? – Hari Apr 12 '17 at 10:25
  • @HarishSingh In pulseaudio, the module bluetooth implements the codecs and registers itself with BlueZ using RegisterEndpoint call during init of the module. From there onwards, whenever BlueZ is connected with new device which is capable of A2DP profile, it calls the "SelectConfig*, SetConfig*" calls in pulseaudio module after NewConnection call request through profile-manager interface. So it's the responsibility of the bluetooth module in pulseaudio to Acquire the FD and read the audio data from the fd. – Parthiban Apr 13 '17 at 05:19
  • @HarishSingh: In BlueZ5.x it's the responsibility of the Audio/external application to implement the same using "media" interfaces. After exporting all the functionalities like "SelectConfiguration, SetConfiguration", you need to register yourself with BlueZ using RegisterEndpoint as mentioned above. For every new device, you will get a NewConnection request and fd after Acquire. Pulseaudio or own application need to read the audio data from fd and playback/route into your sound card using ALSA or gstreamer. – Parthiban Apr 13 '17 at 05:26