What a codec does in a pair of glasses
Bluetooth cannot send uncompressed audio efficiently, so the phone compresses the stream with a codec and the glasses decode it on the Bluetooth audio SoC in the temple. The same happens in reverse for calls: the glasses compress the microphone signal and send it to the phone. A codec is therefore a negotiated agreement between two devices. The glasses advertise which codecs they support, the phone advertises its own list, and the pair settle on one they both understand. If they share nothing better, they fall back to the mandatory baseline.
For open-ear audio glasses, the audible differences between modern codecs are smaller than in sealed earbuds, because an open-ear speaker in a temple is limited far more by its driver, chamber and leak control than by compression. The codec still matters, but for different reasons: compatibility with customers' phones, call clarity, latency for video and battery draw.
The standard codecs for music
SBC is the mandatory codec of the classic Bluetooth audio profile, A2DP. Every device that streams classic Bluetooth audio supports it, which makes it the universal fallback. Modern SBC implementations at sensible settings sound perfectly adequate through an open-ear speaker; poor reputations usually come from low bitpool settings or weak implementations rather than from the codec itself.
AAC is an optional A2DP codec widely supported by phones and preferred by some phone platforms. On those phones, supporting AAC in the glasses avoids a fall back to SBC and can give cleaner results at the same bitrate. Implementation quality varies between SoCs and phones, so AAC support should be checked on the phones your customers actually use.
LC3 is the codec defined for LE Audio, the newer Bluetooth audio architecture built on isochronous channels in Bluetooth Low Energy. It is designed to deliver similar or better quality than SBC at lower bitrates, which helps battery life and robustness. LE Audio also brings new features such as broadcast audio and a more flexible approach to multi-device streams. Support depends on both the glasses SoC and the phone, and on firmware maturity on both sides.
Codecs for calls
Calls use a different profile, HFP, and different codecs. CVSD is the original narrowband speech codec and the universal fallback for calls. mSBC enables wideband speech, which sounds noticeably clearer and more natural, and is supported by most modern phones. Under LE Audio, calls can use LC3 as well. For business call glasses, wideband speech support is one of the most audible improvements a buyer can specify, often more audible than any music codec choice, because it carries directly into how the other party hears the wearer.
| Codec | Profile | Use in glasses | Buyer note |
|---|---|---|---|
| SBC | A2DP (classic) | Music, mandatory baseline | Always present; check implementation settings |
| AAC | A2DP (classic) | Music, optional | Worth having for phones that prefer it |
| CVSD | HFP (classic) | Calls, narrowband fallback | Always present |
| mSBC | HFP (classic) | Calls, wideband speech | Specify for call-focused ranges |
| LC3 | LE Audio | Music and calls | Depends on SoC, phone and firmware maturity |
Latency, battery and Bluetooth version
End-to-end audio delay depends on the codec, buffer sizes in the firmware, the phone and radio conditions. For music it rarely matters; for video and games it shows up as lip-sync drift. Some SoCs offer a low-latency mode per firmware that shrinks buffers at the cost of robustness in busy radio environments. Any latency figure should be stated as typical under named conditions, and no audio glasses should be described as having no delay.
Battery draw follows bitrate and processing load. LC3 can lower the radio and decode load for the same quality, which is one reason LE Audio is attractive for small temple cells, typically about 85 to 235 mAh in total across the category. Music playback across the category typically runs 4 to 13 hours, per spec sheet and depending on volume and codec.
The Bluetooth version on the spec sheet - typically 5.2 to 5.4, with 5.3 most common - describes the radio and link-layer features the SoC supports. It does not by itself confirm LE Audio or LC3; those need explicit support in the SoC, the firmware and the Bluetooth SIG qualification listing. Ask for the codec and profile list rather than inferring it from the version number. A practical approach for a range launching now is to require solid SBC, AAC and wideband speech support on every model, and to treat LE Audio with LC3 as a named feature only on models where the SoC, firmware and target phones have all been checked together on samples. Listing LE Audio readiness before it works reliably on mainstream phones creates support tickets that are hard to answer. The version question is compared in Bluetooth 5.3 vs 5.4 in glasses.
What to specify and how to check it
A codec section on a spec sheet should list the supported profiles (A2DP, AVRCP, HFP and, where present, LE Audio), the music codecs, the call codecs including wideband speech, any low-latency mode per firmware, and the phones and operating system versions on which compatibility is verified per program. It should also name the Bluetooth SIG listing that covers the design; qualification is held by the module or SoC maker and the product listing is completed per program, as covered in Bluetooth SIG qualification.
- List the phones. Name the phone platforms and versions your customers use most.
- Read the codec list. Confirm music and call codecs from the SoC and firmware, not from marketing copy.
- Check on samples. Play the same tracks and make the same calls on each phone; note the negotiated codec where the phone shows it.
- Freeze firmware. Record the firmware version on the golden sample; codec behaviour can change between releases.
- Recheck batches. Confirm firmware version on batch samples during inspection.
Codec support is mostly a property of the chosen SoC and firmware, so it is easiest to secure on a catalog or logo program by choosing the right base model. Typical starting quantities are 50 to 500 pairs per catalog model and 500 to 1,000 pairs per logo program, confirmed in writing per program on MOQ and lead time. Firmware and app options are on firmware and app, and the quote form has a field for the phones and codecs you need verified.