Skip to main content

Topic: Opus as a A2DP codec (Read 2147 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • VEG
  • [*][*][*]
Opus as a A2DP codec
Android Oreo supports SBC, AAC, aptX, aptX HD and LDAC as audio codecs for Bluetooth A2DP. It would be nice to propagate the idea of adding Opus here, so developers of Bluetooth headsets could use a good codec without buying a license (which is required for the LDAC and aptX). Maybe we need a petition?

Also it would be interesting to compare aptX, LDAC and Opus, but it seems that aptX and LDAC aren't available as standalone codecs.
  • Last Edit: 26 August, 2017, 06:46:18 AM by VEG

  • bstrobl
  • [*]
Re: Opus as a A2DP codec
Reply #1
It would definitely be neat if Opus were a useable bluetooth audio codec due to the very low delay (important for audio production and rtc) and excellent sound quality at low bitrates (crowded environments tend to have lower amounts of bandwidth available). Curious how aptx etc. competes.

I believe it was mentioned somewhere that 2 manufacturers have to agree on using it and writing up a spec so that others can implement the codec in their own products.

  • polemon
  • [*][*][*][*]
Re: Opus as a A2DP codec
Reply #2
Well, technically, Opus would work OK, it being a low latency codec, if anything it would be a good codec for things like Bt headsets.

A greater concern I'd say, is the complexity. Opus is relatively complex computational wise, which would use quite a bit of battery power. Using a codec that has a higher latency but is more efficient energy wise, would be preferable, I'd say.

The problem however, is adding another codec to "the list" of the spec: You'd need to update A2DP, AVRCP, HSP, HFP, GAVDP, and possibly a couple other Bt profiles. I'm not sure how these decide on the actual codec to use when establishing or re-establishing a pairing, but I'd imagine it'd break compatibility in a couple places (some Bt speaker not being compatible with phones, etc.) if the decision / handshaking algorithm isn't sophisticated enough.

So if you want to see another codec in that list of profiles and applications, you'd need to release a new set of these profiles, too.

  • bstrobl
  • [*]
Re: Opus as a A2DP codec
Reply #3
All Bluetooth audio implementations need to support SBC as a baseline codec (which is royalty free for this purpose). Worst case, two devices that have differing codec capabilities will simply downgrade to SBC.

As for complexity,  I do believe wireless radios tend to be a much bigger power hog when compared to the small amount of silicon needed to power a hardware audio codec. Being able to transmit less data while keeping similar audio quality may improve battery life in this case.

Here is the email I was referring to from the previous post from Tim Terriberry: http://lists.xiph.org/pipermail/opus/2014-April/002600.html

Here is a rough comparison of current BT codecs:
AptX - 354kbps, 40ms latency
AAC - 256kbps, 800ms latency
SBC - 384kbps, 200ms latency

Please correct me if I am wrong, just did a quick look up. Opus with 20ms latency and excellent audio at 80-128kbps would definitely be an improvement over the older codecs.
  • Last Edit: 27 August, 2017, 02:10:20 AM by bstrobl

  • IgorC
  • [*][*][*][*][*]
Re: Opus as a A2DP codec
Reply #4
A greater concern I'd say, is the complexity. Opus is relatively complex computational wise, which would use quite a bit of battery power.
Recently I have tested  decoders of some popular lossy and lossless on pretty old Motorola E2  smartphone (Cortex A53, quad core 1.2 GHz, 28 nm).
The fastest was LC-AAC  192x and slowest was Opus 52x. And all other decoders were  inbetween these values.
An interesting part that battery life were the same for ALL decoders (50+ hours).  Some expalantion https://hydrogenaud.io/index.php/topic,113981.msg939076.html#msg939076

Even Wavpack "Extra High  lossless compression"  which is 2x more CPU intensive than Opus had just  slightly less battery life (~ 5-10% ) on this not so efficient 28 nm chip.
And even these difference disappears on a newer ARM chips (20, 14, 10nm).  >2x-4x complexity of Opus would be just as efficient as any other codec on these chips.

As of encoders, all formats are pretty fast as well. Opus 1.2.x is very fast actually.

Anyway LDAC is lossless for CD format 44.1/16. Why use any lossy encoder for bluetooth to begin with?
  • Last Edit: 27 August, 2017, 11:36:26 AM by IgorC

  • polemon
  • [*][*][*][*]
Re: Opus as a A2DP codec
Reply #5
A greater concern I'd say, is the complexity. Opus is relatively complex computational wise, which would use quite a bit of battery power.
Recently I have tested  decoders of some popular lossy and lossless on pretty old Motorola E2  smartphone (Cortex A53, quad core 1.2 GHz, 28 nm).
The fastest was LC-AAC  192x and slowest was Opus 52x. And all other decoders were  inbetween these values.
An interesting part that battery life were the same for ALL decoders (50+ hours).  Some expalantion https://hydrogenaud.io/index.php/topic,113981.msg939076.html#msg939076

Even Wavpack "Extra High  lossless compression"  which is 2x more CPU intensive than Opus had just  slightly less battery life (~ 5-10% ) on this not so efficient 28 nm chip.
And even these difference disappears on a newer ARM chips (20, 14, 10nm).  >2x-4x complexity of Opus would be just as efficient as any other codec on these chips.

As of encoders, all formats are pretty fast as well. Opus 1.2.x is very fast actually.
Yeah, but when we talk decoding capabilities, we talk the sort of micro controller decoders found inside headsets, Bt speakers, etc.
This is what I was referring to when I was talking about power concerns. I.e. the computational power inside the Bt accessory, not the phone, etc. While the computational power needed to decode Opus on a phone might be minuscule, it's a much different story for embedded devices like that. The batteries inside those devices are much smaller than a phone battery - obviously. Phones are almost universal computers these days, which are more or less tuned for multimedia applications, so decoding all sorts of codecs in software should be no problem - not even power consumption wise.

bstrobl referred to hardware decoders, which in my book includes ip-cores. Unless you find an ip-core or silicon hardware on a µC capable of decoding Opus, you're running into problems. The problem being mainly fast RAM, not the CPU itself. Fast RAM ("fast" in a µC sense) actually consumes the most power in these applications. When it comes to RF power, on one hand you're right, but this can be alleviated with Bt 4.0-LE probably to a certain extent. The other is, that Bt accessories like speakers and headphones mainly receive RF from a rather strong source (the phone is rather strong in comparison). Similar to like a UMTS/LTE phone is a rather low-power radio compared to a cellular tower transmitter.

A low-power transmitter can be picked up and amplified and filtered rather well with a receiver that has enough power to its disposition. Things like negative SNR signals can be picked up like that rather well, etc. if the signal is shaped correctly. GPS is a well known application of that.

If you want decent and power efficient Opus decoding you need the hardware decoders inside these Bt accessories to be able to decode in - well - hardware. And here's the problem. As long as these chips aren't manufactured, you're out of luck. The best you can do right now, is send Opus data back and forth between devices which can decode Opus in software (which is things like phones, computers, etc). While you may be able to upgrade the firmware on a Bt speaker or Bt headset to add Opus coding in software (however I don't know of any manufacturer willing to do that), you'll run into the aforementioned problems concerning increased power consumption. I.e. existing hardware might be upgraded to add Opus decoding functionality, but because there is not hardware to support that, it all has to be done in software, meaning extra power for RAM and CPU is needed (assuming the µC contains a decent enough CPU, not the sort of cheap-ass stuff often found in toy-grade Bt accessories).

  • jmvalin
  • [*][*][*][*][*]
  • Developer
Re: Opus as a A2DP codec
Reply #6
bstrobl referred to hardware decoders, which in my book includes ip-cores. Unless you find an ip-core or silicon hardware on a µC capable of decoding Opus, you're running into problems. The problem being mainly fast RAM, not the CPU itself. Fast RAM ("fast" in a µC sense) actually consumes the most power in these applications. When it comes to RF power, on one hand you're right, but this can be alleviated with Bt 4.0-LE probably to a certain extent. The other is, that Bt accessories like speakers and headphones mainly receive RF from a rather strong source (the phone is rather strong in comparison). Similar to like a UMTS/LTE phone is a rather low-power radio compared to a cellular tower transmitter.

Actually, most of what people call "hardware" audio decoders are in fact just low-power DSPs running software. Custom silicon is still useful for video decoding, but audio is so cheap to decode that it doesn't actually matter. Now, when you consider the power required by the radio (RF), the (de)modulation (SDR) and the audio amplifier (for headphones), then the cost of decoding isn't a big deal.

  • polemon
  • [*][*][*][*]
Re: Opus as a A2DP codec
Reply #7
[Actually, most of what people call "hardware" audio decoders are in fact just low-power DSPs running software. Custom silicon is still useful for video decoding, but audio is so cheap to decode that it doesn't actually matter. Now, when you consider the power required by the radio (RF), the (de)modulation (SDR) and the audio amplifier (for headphones), then the cost of decoding isn't a big deal.

I was kinda hinting at the SDR running the codec in software in my last paragraph. At least, that's what I was meaning. The power requirements for the transducer amp are probably the largest, so compared to that coded processing is surely small.

But it the point still stands, that manufacturers would have to actually either ship that codec with new devices, or release firmware updates for existing devices. Both things require investing time and money to do that. Even when it comes to new devices, it's easier to re-hash older code, rather than develop new firmwares from scratch.

Unless there is some market pressure for it, we won't see it happen any time soon. Licensing fees might be one of those, but since AAC is almost a must, the license fees are paid, and there's simply no need to invest further money to implement another codec.

  • bstrobl
  • [*]
Re: Opus as a A2DP codec
Reply #8
If I am not mistaken, an AAC encode/decode license still costs 2$. That can be a pretty large part of the cost on a single headphone. The driving pressure to lower costs(people want cheap) may push future adoption of Opus as a bluetooth codec.

  • polemon
  • [*][*][*][*]
Re: Opus as a A2DP codec
Reply #9
If I am not mistaken, an AAC encode/decode license still costs 2$. That can be a pretty large part of the cost on a single headphone. The driving pressure to lower costs(people want cheap) may push future adoption of Opus as a bluetooth codec.
If you want to see a transition, manufacturers would've had to implement both codecs. However once the money is spent on a licensing fee, there's no need to implement the other free codec, simply because that would cost time and money. So that's not gonna happen.

If you'd find a company that is just implementing Opus in their device, that'd be another thing. but  the market pressure is simply elsewhere. Things would have to be changed from the spec side of things: Extend Bt to contain Opus for audio transmission. Then drivers for cellphones and other computers, and only then hardware supporting that codec would start appearing. You can wait for that, sure, but by that time it's mid 2020's and AMR-WB's patents have expired by that time.

Given the wide support, it might be even sensible to have MP3 decoding in embedded Bt devices, because why not? The codec's patents have expired, so it's essentially a free codec now, so why not? The reson: there's no market pressure - the same reason Opus won't see any implementations anytime soon.

  • bstrobl
  • [*]
Re: Opus as a A2DP codec
Reply #10
MP3 and other codecs have a high delay, making the experience sub-par for things like games, audio production etc.
Opus does not have this issue and can deal better with lower bitrates. I sometimes am in a high RF noise area and SBC just collapses horribly making it useless.

Technically there doesn't seem to be any problem in adding in Opus to new devices once a manufacturer decides to do so. They might look at their use case (Voip or whatever) and decide adding Opus support is the way to go.

If there were no pressure at all to do anything we would all be using SBC and nothing else. Clearly there are other codec implementations, even if those take time to implement.

Companies do tend to sometimes look into the future and if an early implementation of something allows them to drop old stuff eventually they might do it if there is sufficient benefit (usually monetary).
  • Last Edit: 29 August, 2017, 03:18:52 AM by bstrobl

  • polemon
  • [*][*][*][*]
Re: Opus as a A2DP codec
Reply #11
MP3 and other codecs have a high delay, making the experience sub-par for things like games, audio production etc.
Opus does not have this issue and can deal better with lower bitrates. I sometimes am in a high RF noise area and SBC just collapses horribly making it useless.
I'm guessing you're talking about games on a cellphone, etc. because when it comes to PC gaming, people will use wired headsets to have zero latency. Sure MP3 has a relatively high latency, but the other codecs in A2DP are exactly used for that case. When you're in a high noise environment, the forward error correction should take care of protecting the signal, not the codec itself. Which codec you use, has technically no influence how the physical layer behaves and deals with errors.

Technically there doesn't seem to be any problem in adding in Opus to new devices once a manufacturer decides to do so. They might look at their use case (Voip or whatever) and decide adding Opus support is the way to go.
Yeah, they might, since they already have implemented codecs for low latency telephony use in their headsets, there is really no reason to spend money on that research, from a economical standpoint. The problem is very easy to state: the time and money needed to do so, is more than zero, with little to no improvement to the average customer and almost no ROI at this point.

If there were no pressure at all to do anything we would all be using SBC and nothing else. Clearly there are other codec implementations, even if those take time to implement.
Yes, you stated exactly that market pressure in your post slightly above this paragraph. The point is: Opus is a competing codec to existing codecs, not filling a gap. Hence since those devices and manufacturing pipelines are already in place, it would be simply an extra investment with almost no ROI. There is or at least there was market pressure to implement the other codecs specifically to alleviate the problems you explained earlier: lower latency, higher quality, etc. pp.

Sure, Opus might make things simpler in a future product, but then we're talking about future products, not existing ones, and certainly not existing industry standards. Solutions Opus offers to existing problems, are already solved by the existing implementations, the cost-benefit factor of replacing or adding Opus to an existing bunch, is simply not worth the effort on the manufacturer's side.
To keep profits secure and at a relatively maximum, they will always stick to industry standards. If you want Opus to be that, Opus has to either be forced to be one, or slowly sub-plant other codecs, but this will take a long time.

Companies do tend to sometimes look into the future and if an early implementation of something allows them to drop old stuff eventually they might do it if there is sufficient benefit (usually monetary).
Yeah, they sometimes do that, when they work on a new product, they look at industry standards (which Opus i not) and implement that, so that it covers intended use-cases and keeps cost (both licensing and implementation) down, to maximize profits.



I'd like to make one thing absolutely clear: I'm not against opus or anything. Completely on the contrary, I love Opus, and I use it wherever I can, simply because it is quite often the best solution almost anywhere. If I could make the decisions, the world would standardize using FLAC1) - Opus2) - Codec23) for the entire audio spectrum, and all would be wonderful. But we live in a real (market) world, where cost factors come from a lot of different angles. While a manufacturer might implement Opus into their devices, that would mean an increase of cost in their product, making it less competitive against the competition. Releasing a cheaper product by replacing other codecs with Opus would put that product into a niche market, ultimately driving the price higher and possibly killing off the product (or the company making it along with it).

  • 1) Because FLAC already [is] a de-facto industry standard, except for certain things like broadcasting, where things like RF64 and BWF are still used, but the EBU is adopting FLAC.
  • 2) Because Opus is quite often the best choice. Other choices are usually only a result of other constraints, like compatibility, etc.
  • 3) Because I think that's the best new low-bandwidth codec right now. Sure it's not "done" yet, but I believe it's gonna be at least what Opus is for the rest of the spectrum (except lossless).

  • Kamedo2
  • [*][*][*][*]
Re: Opus as a A2DP codec
Reply #12
Another Pro: Opus has a good loss robustness and the packet loss concealment (PLC).

  • bstrobl
  • [*]
Re: Opus as a A2DP codec
Reply #13
Looks like only the low latency variant of AptX has 40ms latency, the standard version still has 200ms which makes pretty much nearly all current bluetooth codecs useless for low latency stuff. This is still a deal breaker for me when switching to Bluetooth only headphones (mine still has cable support when needed). Even at 40ms for AptX low latency, Opus still gives a more comfortable 20ms. Not sure how much AptX costs but being a Qualcomm technology, the fees add up. Why support AAC, AptX, AptX low latency etc. when Opus can do the job of all of them?

  • polemon
  • [*][*][*][*]
Re: Opus as a A2DP codec
Reply #14
Why support AAC, AptX, AptX low latency etc. when Opus can do the job of all of them?
Because it's already paid for. It'd cost more to implement and roll-out Opus firmware and keep or even ditch the other codecs, than simply keep paying the royalty and go with what they have. The spec allows it, and it's still the most cost effective solution from a manufacturer standpoint.

You can choose with your purchasing power, obviously. However, I'm not an activist, I wouldn't even know how to be vocal enough to push the market into that direction. You can only hope for a revised version of future products, getting firmware updates is gonna stay nothing but a dream.

On a more brighter note: I've heard Opus is making it into VR! It's only a matter of time, when VR headsets become wireless, so that's gonna be a strong influnce, I believe! There's no reason why VR headsets cannot be implemented on top of (a future) Bt profile. So, since Opus is already in there, it might just set that in stone, etc. Similar to how Youtube is pushing for Opus compatibility of handheld devices. Was and is, actually.

  • Rollin
  • [*][*][*][*]
Re: Opus as a A2DP codec
Reply #15
Anyway LDAC is lossless for CD format 44.1/16.
Sony site (https://www.sony.net/Products/LDAC/) tells maximal bitrate is 990 kbps. How can it be lossless with 990 kbps if some tracks (real tracks from real CDs) in 44/16 cannot be compressed even to 1100 kbps even with Monkey's audio and Optimfrog with strongest settings? Or is info about 990 kbps wrong?