Why many TWS earbuds are capped to 128 kbit/s AAC?

I’ve been using SOUNDPEATS Sonic Pro Bluetooth earbuds for almost two years, and I like them. By today’s standards, they’re a fairly basic model featuring no ANC/transparency modes, no equalizer or auto-pause upon unplugging.

Unfortunately, left earpiece of this otherwise nice and comfy pair started sounding noticeably quieter. While I could adjust the audio balance on my device, Android’s global balance setting means I’d have to reset it to zero every time I connect different earphones.

So, I decided it was time to try something new, and my eyes landed on this season’s latest release from CMF: Buds 2 Plus.

A brand new model with lots of features! “Personal Sound” tailors the equalizer curve based on your hearing profile, while “Spatial Audio” controls binaural panning, and what’s also important, these earbuds have 6 microphones for improved call clarity. That’s exactly what I wanted, as SOUNDPEATS fall short in this aspect, offering both lower-end microphone sound quality and poor wind detection.

The CMF Buds 2 Plus sport a 12 mm LCP driver with “enhanced clarity & deep, powerful bass” and are Hi-Res certified. The bass is indeed deep and powerful, too powerful to my taste, even with “Ultra Bass” turned off.

However, within the first couple of minutes of listening, I encountered unpleasant audio artifacts. Complex tracks sounded like a regular low-bitrate audio file, with cymbal hits unnaturally smoothed out (making “sss” sound instead of “tsss”), and bass drums barely present. On top of that, there’s a distinct metallic echo.
It just didn’t sound right for earbuds in this tier.

After trying different settings, equalizer presets, toggling game (low lag) mode on and off, I found High-quality audio menu, which lets users switch between AAC and LDAC codecs..
The application has informed me that LDAC may “reduce battery life and result in choppy audio”. Switching the codec to LDAC did the job: the audio was finally great, as it should be from the beginning!

But why was it poor with AAC? Even more, why it becomes better with SBC, if I switch to it manually using developer settings on my smartphone?
For comparison, my previous earbuds didn’t have this issue. Whether using SBC, AAC (or aptX for that matter), they delivered solid sound without any obvious artifacts.

Curious about the root cause, I’ve ended up capturing and analyzing Bluetooth traffic between my Linux PC and the earbuds.
It turns out that:

• SBC codec is artificially limited to 250 Kbit/s (max bitpool = 39)
• AAC codec is artificially limited to 128 Kbit/s

Patching PipeWire to force 320 kbit/s

PipeWire, the audio server of Linux, handles not only regular audio cards, but everything Bluetooth-related as well.
By tweaking single MIN_AAC_BITRATE constant in a2dp-codec-aac.c file, I forced the server to negotiate 320 kbit/s AAC, which CMF Buds 2 Plus happilly accepted despite the imposed limit.

--- a/spa/plugins/bluez5/a2dp-codec-aac.c +++ b/spa/plugins/bluez5/a2dp-codec-aac.c @@ -19,7 +19,7 @@ static struct spa_log *log; #define DEFAULT_AAC_BITRATE 320000 -#define MIN_AAC_BITRATE 64000 +#define MIN_AAC_BITRATE 320000

With this change, the audio quality is great now, without any hiccups or interrupts from the higher bitrate. It wasn’t some kind of hardware limitation of the earbuds, just a low-bitrate configuration.
Huh!?

Huh. All right.
My forum post hasn’t been approved in 8 days, despite being visible to the moderator, from whom I received another reply.

Was it done for pure marketing reason, or is there any technical basis for such configuration?

Why Limit AAC to 128 kbit/s?

Could it be about power consumption? Are they trying to target longer battery life with low-quality AAC?

The website shows drastic battery differences between AAC and LDAC:

Is this really the case?
Does AAC 128 kbit/s consume that much less than AAC 320 kbit/s?
Does LDAC consume much more than AAC due to its complexity?

I always thought of LDAC as of low-complexity codec due to its high bitrate, but it’s hard to call AAC-LC (Low Complexity) exactly low complexity codec either.

Well, the only way to find out is to test them all!
The test was performed with the same volume level, with ANC off but Personal Sound enabled, on the same music set.

13:06 12:33 (2 attempt)	10:56	11:04	9:32	9:24	11:15

And indeed!

• AAC 256/320 kbit/s reduces battery life by at least 1 hour 30 minutes compared to 128 kbit/s
• LDAC lasted 3 hours less than AAC 128k, though 1.5 hours longer than expected
• SBC, despite being lower-complexity, performed similarly to high-bitrate AAC

The reason for these differences remains unclear

Does more data increase pure CPU time? Or is it SRAM which stays in high power mode longer? Maybe more data does not fit into single DSP word and forces it to process in more ticks? Could it be the radio, which power amplifier is enabled longer due to more frequent ACK packets?
I don’t have the answer.

Checking other earbuds

Thanks to btcodecs project, I have traffic dump data from thousands of devices, allowing me to examine AAC bitrates across various earbuds.

Surprisingly, low bitrate AAC is rather common in the industry:

Nothing	Ear (1)	160 kb/s
CMF	Buds 2 Buds 2 Plus	128 kb/s
OPPO	Enco X Enco Free2 Enco Free3 Enco Air3	128 kb/s
OnePlus	Buds	165 kb/s
	Buds Pro 2	128 kb/s
	Buds Z2	145 kb/s
Xiaomi	Mi True Wireless Earphones 1 Mi True Wireless Earphones 2	96 kb/s
	Air 2s	128 kb/s
realme	Buds Air 3 Buds Air 3s Buds Air 5 Pro	128 kb/s

But AAC 128k sounds all right to me! How come?

It all depends on the encoder and its configuration.

Android uses FDK-AAC software encoder from Fraunhofer institute, which:

1. Does not do amazing job at lower bitrates for AAC-LC
2. Has a default 17 KHz band limit filter, applied at all bitrates (Android does not disable it)

However, the decoding could be offloaded to the hardware implementation or DSP chip, and it could be, and usually is, of higher quality.
I don’t have any information regarding the SoCs or smartphones which incorporate hardware encoding.

Apple uses its own top-quality encoder on iPhone, delivering exceptional sound on low bitrates, but 128 kbit/s is still just barely enough for good audio, even with the best encoder in the industry.

Another major factor? Your age.
As we age, our ability to hear high frequencies declines. Most audio codecs allocate bitrate across mid-to-low-to-high frequencies, and if your ears are aged, you might not hear the mess in the highs, where the artifacts are present the most.

This is especially true for younger audience: 17 KHz cutoff in Android’s FDK-AAC won’t sound perfect even with 320 kbit/s if you have another codec to compare. Again, this may not be true for hardware encoder.

Unfortunately (or, fortunately) my hearing limit is around 15.5 KHz—I can barely hear old CRT TV scan frequency.
You can your frequency response on Online Tone Generator website.

How can you check the bitrate yourself

• Windows: use Bluetooth Tweaker
• Linux: use avinfo

Currently, btcodecs project does not show AAC bitrate. The website will be updated soon.

If you have Bluetooth traffic dump, you can use Wireshark to check the bitrate.
Apply btavdtp.media_codec_audio_type==0x02 filter and look under
Bluetooth AVDTP Protocol → Capabilities → Service: Media Codec - Audio MPEG-2,4 AAC → Bit Rate
in the bottom of the list.

Final thoughts

While CMF Buds 2 Plus allow user to switch to LDAC for proper music experience, buyers of regular CMF Buds 2 (non-plus) will be stuck with 128 kbit/s AAC only, and I honestly don’t see any reason other than marketing to be proud of the large and high-quality driver in the earbuds if you can’t use it to its full capability.

If CMF wants to improve user experience, they should introduce a bitrate configuration option in their app, letting users balance between audio quality and battery life themselves.

I’ve got ripped, LAME! ^(v3.98)