24

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)
  • This article says "Android users are in luck, as modern Android phones do support AptX. Unlike on Windows, it’s even possible to check if the connection is using AptX!" But no explanation of how. – endolith Nov 13 '18 at 3:27
10

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.

  • 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. – dvim Nov 23 '14 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 Nov 25 '14 at 6:47
  • 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. – dvim Nov 25 '14 at 10:42
  • Thanks again @Martynas. Even though the 730 has better reviews, grabbed an LG HBS-750 for testing. Same suite of codecs as the 730. Have forked your repo and added another capture here. Unfortunately, in both of our captures the phone is choosing to use SBC instead of mp3. Not sure what media file type you used, but my CM 4.2.2 test used 128kb/s VBR mp3s (deliberately small bitrate to avoid stressing the BT bandwidth). Beginning to think ce4 might be right about the licensing issue. – ewedel Jan 18 '15 at 11:03
  • The eiditing of ` /etc/bluetooth/bt_stack.conf` didn't seem to work, but I had exact same setting in developer settings and that worked. Thanks to your answer I managed to find out that Parrot Zik 2 uses SBC most of the time. – Zero Jun 22 '16 at 9:35
8

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).

  • 2
    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
7

With Nexus 4 (5.0.1) or Nexus 7 (2012)(4.4.4) devices it is possible to use the developer mode to get the btsnoop_hci.log. "Enable Bluetooth HCI snoop log". It is not necessary to root the devices. It seems that both devices don't offer aptx. I test this with Moto Stream (no aptx) and Philips AEA2500 (with aptx).

  • 1
    I'm on CM 12.1 and this potion is also available to me. Perhaps it is on all recent phones. Thanks. – pedro_sland Dec 22 '15 at 9:42
4

[Credit for this answer mostly goes to ewedel, who clarified that the answer is in the btsnoop_hci.log file, using Wireshark; and prittstift69, for sharing the easy way to create this log file.]

This is a newbie-friendly, step-by-step tutorial, summarizing answers already given, with some interpretation of the results from me.

As prittstift69 and others mentioned, you can "Enable Bluetooth HCI snoop log" under Developer options. No need to follow the more complicated approach suggested by ewedel.

  1. Start by turning bluetooth OFF on the android device (I'll call it 'phone').

  2. Turn on Bluetooth HCI snoop log under Developer Options.

  3. Turn ON Bluetooth on the phone and connect it to the Bluetooth receiver (I'll call it 'receiver'). This step assumes that the receiver had been previously paired with the phone.

  4. Play music on your phone (ideally an uncompressed WAV or FLAC file). Ten seconds is all you need. (Probably even less)

  5. Turn OFF Bluetooth on the phone.

  6. Turn OFF Bluetooth HCI snoop log

  7. Transfer the file btsnoop_hci.log (I found it in /sdcard/Android/Data/) to your computer. Run wireshark on your computer and open the file btsnoop_hci.log

  8. Filter for "btavdtp" (no quotes) Search for a message from the phone to the receiver "Sent Command - SetConfiguration ...." This is the message sent by the phone to the receiver with the final configuration to be used for this audio after the handshaking is completed. The text in the Info field will tell you what the final configuration was.

[SBC] If it is SBC, you may want to know what the bitpool is. To do this, remove the Filter for btavdtp and look for a message with Protocol SBC and click on it. Below, in the details section, expand the Bluetooth SBC Codec information. Then expand any (or all) of the Frame data. There, it should clearly show the Bitpool used by that Frame. If it is 35, there is a good chance that your sample rate is 44.1 kHz, you are using Joint Stereo, and using the Middle Quality SBC audio profile (http://soundexpert.org/news/-/blogs/bluetooth-audio-quality-a2dp). The bitrate for the compressed audio is then 229 kbits/sec SBC, which scores a 4.68 in Sound Expert's testing (http://soundexpert.org/encoders-224-kbps) which is comparable to mp3 around 110-130 kbits/sec.

[APT-X] If it is APT-X, then both your phone and receiver support APT-X, and that is what it is using. Assuming 16-bit, 44.1kHz, the codec is running at 352kbits/s.

  • "ideally an uncompressed WAV or FLAC file" Wouldn't you want to play an MP3 to see if it sends it as MP3, etc? – endolith Feb 20 '17 at 14:44
  • 2
    Only if your goal is to see if A2DP supports mp3 on both sides (a valid question). However, my experience is that mp3 support on both sides is rare (I have never seen it on any of my devices, and I've had quite a few). So, at least with Android devices, your most likely A2DP codec options are SBC and APTX. Playing an uncompressed audio file forces the phone to re-encode. – klaberte Feb 20 '17 at 16:53
  • I didn't write an answer – endolith Feb 20 '17 at 17:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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