Apple iPhone OS 3.0 shines fresh light (and enmity) on A2DP Stereo Bluetooth

So it’s clear from my Google Analytics data that since the release of iPhone OS 3.0, there is a heightened interest in Bluetooth stereo audio. There is also concern about its quality, and whether it sounds like shit on purpose.

Well let me tell you, something funky is definitely going on with the Bluetooth stereo audio performance on the iPhone. Your suspicions are not unwarranted. The bottom line is that Bluetooth A2DP as implemented in the iPhone will sound like shit. Anyone with an ear (but not a preference) for audio distortion will corroborate there is a ton of it when listening to Bluetooth wireless audio on the iPhone running 3.0 OS. High frequency sounds such as symbal-hits sound like digital-ringy-thrash-crap. Awful. Un-listenable. Period.

After poking around a bit, it seems (I suspect) Apple may be short-changing users on the bitpool allocation. From an internet discussion regarding hacking BT performace via Windows registry, it is noted that the Bluetooth A2DP implementation guide outlines how to adjust over-the-air quality for A2DP:

Medium Quality
BitPool=35, SampleRate=44.1khz = 229kb/s
BitPool=33, SampleRate=48khz = 237kb/s
High Quality
BitPool=53, SampleRate=44.1khz = 328kb/s
BitPool=51, SampleRate=48khz = 345kb/s

The trade-off is of course weighed and excuted by Apple. It appears, and logic would backup, that the source device in the A2DP link is the “decider” for the bitpool. The setting, that is, that determines bitpool is embedded in the iPhone itself, rather than the receiving BT accessory.

All bitrates are not created equally

Do NOT be fooled. The bitrates you see above are not typical compression bitrates you are used to seeing in your desktop music libraries. BT doesn’t use a fancy psychoacoustic lossy compression scheme like MP3 or AAC (optional A2DP codecs, btw, but neither employed by Apple). The standard for A2DP Bluetooth uses sub-band coding (SBC) for compression. SBC is royalty-free, low complexity, low latency, and by many measures, a crude form of compression. The bitrates that apply to it do not yield the same sound quality at comparable bitrates of MP3 or AAC. Some estimates are that you require 3x the bitrate to achieve comparable quality to MP3. To highlight just how much better MP3 and AAC are consider, AAC and MP3 are not royalty free, and in spite of that, they are employed in infinitely more places, and are thus commercially acceptable. You get what you pay for, people.

Doubling down on lossy

Also keep in mind that you are *re-compressing* an audio file that has already been uncompressed from a lossy codec (MP3 or AAC). Meaning, the original CD-quality track (1411 kbps) was compressed using some (better) codec like MP3 or AAC. Do it once and the quality is very acceptable for most consumers at 192 kbps or above, even if it is mildly, and unarguably, degraded from the original source file. Here’s where A2DP gets nasty. It takes this degraded uncompressed file, and compresses it again, this time using a particularly crude compression scheme, SBC, and what you are left after wireless transmission and local uncompression in the speaker is a audio file that is ridden with tandem artifacts from daisy chaining multiple lossy encode/decode cycles. Nasty.

WWJD

Now if Apple increased the bitpool, what would happen? Would this solve all the issues with current BT audio quality? Not really. Audio quality would improve, but likely only slightly, because you still don’t conquer the tandem artifact issues. Transmission range would decrease and power consumption would increase – owing entirely to the increased use of bandwidth and its increased transmission duty cycle required to ship more data nominally.

Practical remedy

The right answer is to support MP3 or AAC via Bluetooth – possible and feasible because as mentioned, either are supported optional codecs for A2DP. This means you would not have to decompress a file that is already in the format you are sending over the air. You send it over in its orginal compressed state, then you decompress it once at the receiver. There are some non-dealbreaking implications that must be considered:

1. The receiver must carry the cost of a royalty in order to decode the Mp3 or AAC. That’s a bummer for accessory makers. It’s not big, but it also hard to get paid for by the consumer, so it eats right into margins. What ends up happening is accessory makers will choose to only support the optional codec in a premium product offering, and run the risk of embedding the low-performance SBC option in entry level products or leaving it out altogether cause it more or less sucks.
2. It is difficult to support BOTH Mp3 and AAC, meaning Apple would likely choose to support AAC as this is the format they sell via iTunes, and so it would make sense that they would want to offer the best audio experience with the format they are purvey. This is also something that is a bummer for consumer who for the most part still trade and burn in mp3.

Bottom line

• My recommendation as a product developer, but more importantly as a consumer, is that Apple supports MP3 as an optional A2DP codec for the iPhone. I’ll take AAC as a second choice… but it’s more evil as there is so much music I simply won’t convert to AAC, and I will resent having to buy all my music I want to enjoy wirelessly from iTunes.
• Consumers will reject the audio quality currently offered in the iPhone’s A2DP standard implementation.
• Accessories will lack efficacy in their wireless audio feature, and the brands that do this will be at risk of taking the heat for the poor performance. This will hamper implementation of the feature in the accessory space.
• These last two bullets, unaddressed, are the two major factors why I predict Bluetooth stereo audio will fade into history, which is sad, because there are dozens of engineers who’ve worked very hard to get it so close to the original vision’s intent. To see it still fall short is depressing.

—

Related articles from wirelessaudioblog.com: here on announcement, here on BT headphones.