Take the 2-minute tour ×
Android Enthusiasts Stack Exchange is a question and answer site for enthusiasts and power users of the Android operating system. It's 100% free, no registration required.

Bluetooth's Audio Profile A2DP supports multiple codecs. All devices have to support SBC (subband codec), then they can support additional "optional codecs" like MP3 and AAC, or "non-A2DP" codecs like apt-X.

Of course these codecs can't actually be used if the receiver doesn't also support them, in which case both devices fall back to SBC.

  1. How do I find out which codecs my hardware/ROM support?
  2. How do I find out which codec is currently in use? (Maybe this depends on the track, too, if it passes MP3/AAC files directly without re-encoding, for instance)
share|improve this question

2 Answers 2

Looking at the source, there are at least 4 codecs: SBC (mandatory), MP3 (MPEG12), AAC (MPEG24) and Sony's ATRAC.

./android/external/bluetooth/bluez/audio/a2dp.h:  
#define A2DP_CODEC_SBC          0x00
#define A2DP_CODEC_MPEG12       0x01
#define A2DP_CODEC_MPEG24       0x02
#define A2DP_CODEC_ATRAC        0x03

The underlying software is linux' "bluez" stack. It supports SBC and has limited MP3 capabilities.

The changelog for v3.25 (2009?) reads: "Add limited support for MPEG12/MP3 codec".

./android/external/bluetooth/bluez/ChangeLog:
ver 3.25:
    Add limited support for Handsfree profile.
    Add limited support for MPEG12/MP3 codec.

See also the v3.25 announcement. MP3 support seems to depend on gstreamer which is not available on Android, so I just guess SBC is the only option for A2DP to boot.

PS: Most A2DP devices seem to lack support for MP3/AAC due to patents/licencing issues (including Linux).

share|improve this answer
1  
Those are 3 optional codecs, yes, or it can use other codecs like the Galaxy S III using apt-X. I thought encoding was provided by hardware, though? Android can play MP3s so I doubt there are any patent limitations. –  endolith Jul 24 '12 at 21:49
2  
I don't think SBC has a dedicated hardware encoder in Android devices. It's computationally modest so I guess it's done in software. At least the sources indicate that. PS: I'm looking at Cyanogenmod's source, not HTC's or Samsung's. PS2: I meant the audio sink devices on the other side with lack of mp3/aac (headsets, etc.) –  ce4 Jul 24 '12 at 22:03

On my Cyanogen 10.1 phone (AOSP 4.2.2), it is possible to enable a capture of bluetooth traffic. You can then load this capture into Wireshark and look at the negotiation phase to determine which codecs the paired audio output device supports. Not sure what OSes support this: when I first ran across this method it claimed support only from 4.4 onward, but clearly not the case with CM on a Doubleshot. :-)

Assuming you have the requisite setup (rooted ~ 4.2.2 or later), these are the steps:

  1. pair your phone with the A2DP device of interest
  2. disable bluetooth on your phone
  3. edit this file: /etc/bluetooth/bt_stack.conf, changing the BtSnoopLogOutput setting from its default value of false to true. For this I use ES Note Editor, launched from ES File Explorer after enabling its "Root Browser" setting.
  4. start CatLog, with all logging types enabled
  5. enable bluetooth on your phone
  6. after it pairs with the output device, play a snippet of audio with your player of choice (I use Apollo). Ten seconds or so should be plenty.
  7. disable bluetooth again
  8. stop CatLog's logging and save off its log file to your SD card
  9. [IMPORTANT!] edit bt_stack.conf, changing BtSnoopLogOutput back to false.
  10. copy the BT capture from your SD card (/sdcard/btsnoop_hci.log), along with the saved CatLog file, to a computer with a current copy of Wireshark installed.
  11. load the capture file into Wireshark and set a Wireshark display filter of "btavdtp" (no quotes). You'll now see a few packets only, look for the output device's reply to the AVDTP GetCapabilities query and you'll have your answer.

You can also line up the capture timestamps with the CatLog log's timestamps to look for suggestive log entries. I found a couple and cleverly forgot to include them in the notes upon which this post is based.

Once I have some more time am hoping to reduce this rather lengthy set of steps down to an app, but not sure if it's possible and won't have the time yet for a while anyway. Meanwhile, suggestions to improve on the above process are welcome.

share|improve this answer
1  
Thanks. This worked great. I did not find anything relevant to capabilities in the CatLog logs. Anyway, tried it on Moto G (2013) running CM 4.4.2 and with LG HBS-730 headset. No apt-X in the logs, because CM does not have proprietary libs for that. –  Martynas Nov 23 at 17:54
    
Thanks, @Martynas, good to know. Did it include support for mp3? I'm wondering what might be a good target for testing that my phone supports mp3. Car radio doesn't unfortunately, and I haven't found any (!) product which documents its A2DP codec support. Regarding CatLog, wasn't thinking the actual codec list would be in there so much as some suggestive messages which could be used to search the source code. Another day.. –  ewedel 2 days ago
1  
So a response to Discover returned three audio sinks. A response to GetCapabilities for ACP SEID [2 - Audio Sink] included Service: Media Codec - Audio MPEG-1,2 Audio which had MP3: True. I have uploaded captured log file to github. –  Martynas 2 days ago

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.