Because the bandwidth, bitrate and audio codec for HFP profile hasn't been upgraded in a decade. AptX and co. are only used in stereo profile with no mic support. As soon as you request bidirectional audio it downgrades to horrible old codecs.
aptX LL actually supports bidirectional audio. There's also the Faststream codec that does SBC in both directions. For some reason almost no one implements any of these and we're left with atrocious HSP/HFP profiles.
> LL was unfortunately discontinued by Qualcomm. AptX adaptive is all that remains and it unfortunately has more latency than LL but probably less clicking and microsecond dropouts which I assume is why Qualcomm moved away from LL along with LL requiring dedicated antenna hardware
There has been no new features or changes in bluetooth audio for two decades. The new LE audio is the first new version ever since a2dp was introduced.
It's more of a latency thing, though modern codecs should be able to move past that restriction. Most HFP devices still drop into mid '90s mode for call audio.
That's surprising to me. It's very distracting to watch a video of someone talking that has even a slight audio sync issue. The noticeable delay when watching a video is surely greater than the delay required for people to start talking over each other.
Either you are participating in a audio or video call and your audio is bidirectional or you are watching a video with stereo sound. If the latter the video player should buffer the video and adjust the delay of showing it to match up with the delay of the audio sink. If not there is a problem in your device.
> But the one freaking thing I cannot understand is why after almost 20 years of wireless audio in computers, the microphone quality is still atrocious.
Off the top of my head:
1) Wireless noise from other devices: WiFi signals from other devices can cause disruptions to Bluetooth signals.
2) Packet drops: Some packets from could be lost during the wireless transmission.
3) Software issues: Anything from outdated audio drivers, to dependency requirements, to the CPUs being hogged by something running in the background.
4) USB 3 interference: Apparently USB 3 introduce interference to the 2.4GHz range when it's being used.
Those don't come into play here though. The problem with mic quality with Bluetooth is that we're still using the old headset profile for bidirectional audio. That means bidirectional Bluetooth audio maxes out at a sample rate of 16kHz and bitrate of 64kbit/s, with an ancient compression codec at that.
I don't understand why nobody has fixed that. Even Apple, known to extend the Bluetooth spec to improve UX, seems to use the HSP for bidirectional audio between a Mac or iPhone and AirPods. I don't get it. Even if you kept the 64kbit/s bandwidth but switched to AAC you'd get a significant audio quality improvement since you could at least represent sound over 8kHz.
"As per our usual business processes, the licensing of aptX, Snapdragon Sound and the underlying technologies, will continue to remain unchanged apart from contributing the aptX and aptX HD encoders to AOSP."
Open source != free to use anywhere. (In this case)
That's not OSS. That's just some random permissive license.
OSS is "there is no tresspassing". It's as close to public domain as you can get with software (because public domain software has some weird caveats in the US from what I remember).
In a sort of off topic question which I had for two years now. If the world, or vast majority of the world are using wireless headphone or speakers. And all using codec with the Bluetooth profiles. Shouldn’t we just encode the original music ( Original as in Spotify and Apple Music ) with those codec to avoid conversion lost? Even AAC on Bluetooth headset are not pass through.
Right now everything you listened to on wireless are being re-encoded and decided on the fly.
Not really, encoding (compression) is first and foremost about saving bandwidth. And bandwidth is sometimes limited, for the same reason your Wi-Fi network gets slower as you get further from it, or if interference is received (microwave, neighbors downloading, etc).
You have no choice but to reduce bandwidth, or start losing data on the link. Instead, you'll transmit more parity data, and maybe switch to less sensitive encoding schemes.
Depending on the bounds you expect to be working in (ie, 10-100 Mbps is more comfortable than 3-5000 kbps), you pretty much need variable bitrate codecs to gracefully handle the (often temporary) bandwidth dips.
Everything is a tradeoff: frequency ranges could be enlarged to increase bandwidth at the cost of interference, transmission power at the cost of energy efficiency and interference. And you can't do a lot (except beamforming) against propagation losses, so expected ranges have to be taken into account as well.
It is true that the above makes less sense if audio is transmitted ahead of time, which makes it not latency-sensitive. By then though, why bother with that specific encoding? You're usually limited by memory on the receiving side, however.
In practice, this can't actually happen because what if you need to play a notification sound? Then you would need two different streams to send to the device without having to reencode everything.
I can't think of any technical reason why companies cannot work on changing their audio stack and adding to the next Bluetooth specification to support this scenario. I am not sure what would be the benefit to doing this work through, other than saving encoding stop on the device side.
This but in general this isn't how audio APIs are structured. Some apps would do their own decompression, for example. Some may want to do some additional processing on the PCM data as they play it. In general, all related APIs and apps are built with the expectation that decompression happens locally on the device. It would be a massive undertaking to change that.
How would this work for gaming and phone calls? How would the operating system know whether you're playing music, or gaming/phone calls? Would you want your OS to know whether you're playing music or gaming? (personally I wouldn't, since not for every application it'll be obvious what it is and it's guaranteed OS will make annoying wrong choices)
Easily, just like any other passthrough. It doesn't need to know what the application is, just what the application is trying to do.
So application would check the capabilities of the audio sink, compare that with properties of the source, and if they match, just shuffle the buffers without decoding; let that be a concern later in the pipeline (i.e. hardware). Done.
> Would you want your OS to know whether you're playing music or gaming?
... Is that a trick question? Yes. My OS is not a malevolent entity from which I should hide everything. It's going to know it anyway. Who sends audio packets to the sound card?!
Not everything at all is using wireless - think about any home stereo or speaker setup.
Also do we really want to move to even LOWER quality codecs for the source material on streaming services? We should be pushing for the opposite - higher quality source material.
I was thinking of Lower quality codec but with higher bitrate. Instead of source material being 256Kbps AAC, we could be doing 800Kbps with a low latency codec but zero re-encoding.
AptX (even the non-LL one) is the only codec I know that has acceptable latency where it's even good enough for gaming.
Sony WH-1000XM3 had AptX, WH-1000XM4 does not and other latest generation ANC headphones also do not.
So headphones from 5 years ago are more useful than modern ones. Modern ones are so bad, if you stop a song you hear the song still playing a bit after you pressed stop.
Might this open sourcing increase the likelihood of acceptable-latency first-tier ANC headphones again?
Or are they still going to be like "open source is too open, let's keep using my own high latency proprietary codec anyway and add a few ancient even higher latency ones like SBC for compatibility"
> So headphones from 5 years ago are more useful than modern ones. Modern ones are so bad, if you stop a song you hear the song still playing a bit after you pressed stop.
I have similar observation. 3-5 years ago it was easier to find headphones with that support multiple codecs. Now aptx is kit always supported.
Reading between the lines - decoders aren’t included, which would seem to suggest that you will still need Qualcomm patents for that. Maybe I’m misreading?
Indeed it's just the encoders. Qualcomm seems to reserve the decoders as a unique selling point for their silicon, as far as I can tell they won't license them out for use on any competing hardware. Every teardown I've seen of a device which supports decoding aptX has had a Qualcomm Bluetooth SoC inside.
Last time I worked with aptx directly was in the CSR days, but they used to have a library they'd provide in binary form only for your specific platform and compiler settings. It was fuck-off expensive ($1+/device + certification), so the easier way to do things was just to buy their silicon which had the IP "for free". A couple years back someone put a decoder of dubious legality into FFMPEG [1], though. The code was subsequently migrated into bluez as well.
Why dubious ? FFMPEG is not incorporated in the US and does not recognize software patents. All the popular codecs such as h264, h265, etc. are similar in nature.
Because it was reverse engineered from binaries, not cleanroom. I certainly wouldn't risk using it for a product, much less advertise it as a feature given Qualcomm's history in this space and the myriad ways they can make your life absolute hell even if you're 100% in the right. Qualcomm is not a nice company.
I meant that a large number of codecs supported by FFMPEG are patent encumbered, and nobody ships them in the US. This is well known. Even distros based in the US such as Fedora/RHEL do not ship them out of the box. So clean room v/s reverse engineered gets into a secondary issue that is mostly moot.
Sure, but since Qualcomm is never going to give anyone a license to use it and the lack of cleanroom means the provenance is somewhat uncertain, I think "dubiously legal" is a perfectly acceptable description. It's not like I'm saying it shouldn't exist or anything. Just, be aware that the semiconductor mafia considers this part of their turf and wear some kneepads if you're going to make money with it.
LDAC is pretty well established in over-ear headphones now but I think it's still quite rare in true-wireless earbuds? Typically you only get some version of aptX and/or AAC.
Even new super premium wireless cans like the Focal Bathys don't have LDAC. Despite Samsung being the most popular Android vendor and famously having LDAC but not licensing AptX. One would need to use SBC with the Bathys on a Samsung. Although it was quite established, LDAC seems to be used less and less, I wonder why, license fees?
> Despite Samsung being the most popular Android vendor and famously having LDAC but not licensing AptX.
Samsung implemented LDAC because they use two different HW-platforms: Qualcomm and Exynos. When using Qualcomm the AptX license comes free, for other platforms it should be licensed.
To have feature-parity in a device-model using both platforms (like Galaxy S-series) Samsung implemented LDAC on both and AptX on none.
Not sure how this will play out now that the latest flagship Galaxy S23 is no longer using Exynos platform, but apparently AptX is still not implemented. Meanwhile they developed their own codec called SSC ("Samsung Seamless Codec" or sthg), so I expect their opposition to AptX to continue (hopefully LDAC is here to stay though...).
> Although it was quite established, LDAC seems to be used less and less, I wonder why, license fees?
For headphone-vendors:
If you are a larger manufacturer, use a Qualcomm chip and apply AptX, you qualify for marketing support from Qualcomm.
If you see an AptX logo on an advertisement, it's likely that Qualcomm gave some marketing support funding to drive adoption of AptX/AptX HD.
--> I strongly suspect that a qualification criteria for this funding is to not implement other "HD" Audio codecs like LDAC (as it aims to establish a standard for "Bluetooth HD audio")
Soundcore and Xiaomi have added it to all their newer TWS. It does lower battery life compared to aptX from my understanding, so hopefully they will add it in the future.
Making me wonder if I should update my Soundcores. I have the exercise oriented ones (with the little ear hooks) but firmware updates have been pretty smooth so far.
Sound-wise, there are no alternative, LDAC with its quality profile at 990kbps wins by brute force. aptX is not even close in terms of quality (compared to non-BT codecs, wired connection with 128kbps opus wins by landslide against any BT codec. checked that on a decent headphones + usb/bt DAC)
P.S. maybe not just a codec, maybe BT stack ruins sound somehow
aptX is still free to implement on the encoding side, like on Windows or macOS or Android, but you need a Qualcomm chip on the decoding side, like on earphones or speakers, so I wonder if it makes much difference even if the decoding side becomes open source.
I'm trying to find reference, but I believe Fraunhofer has a bunch of patent encumbrances on LC3. Although maybe software encoding & decoding licenses are free? The tests where LC3 were chosen over Opus seem semi-dubious too, with only the general audio Opus codec tested at low complexity, in a speech test. I'm not sure but I think/hope Opus hardware implementations would not be hardware emcumbered, but I'm not certain. For headsets this can be a significant power consumption win.
LC3 is not a high quality codec. It's a decent quality low bit-rate codec. Fraunhofer has a complementary lc3plus but it's unclear what grants of use there are on it to me.
Qualcomm here with Apt & AptX has notably not released decoding grants of use at all. This allows systems to output AptX, to the benefit of Apt/aptx receivers having better support, and they all pay Qualcomm & I expect largely use Qucomm chips. This is opposite to the longstanding case of Dolby Digital 5.1 & newer, where many computers have decoders, but Dolby Digital or Dolbt whatever encoding is ultra ghastly super rare. People were keeping their ancient ass Nvidia chipset motherboards from 2001 because it was like one of the only rare options available.
It's deeply scarring to me that so many of the important relevant ways to send data around, that define our digital world, are so jealously guarded secrets. We raise worse people on this planet by denying them curiosity & experimentation & playing with stuff, and a huge subsector of our critical AV systems is deeply shrouded in red tape & black boxes.
This is funny, but google actually added opus for BT in recent version of Android, for some unknown internal reasons (maybe 5.1, VR or so). No one using it obviously though
It's the first mandatory lossy codec in Android for microphones (so far they only required PCM and FLAC).
There's surely a benefit in scenarios with more than 3 microphones, i.e. in Automotive...
This is excellent news, aptX HD in particular is a great sweet spot for latency (for video), high enough quality, and robust enough encoding to avoid dropouts.
aptX HD is one of the greatest things happened with Android ecosystem. One day I just bought a cheap BT-receiver with aptX HD support and optical output and connected it to my old-fashioned music system (receiver + amp + floorstanding speakers connected by wires). The music quality became so much better compared to 3.5mm jack and I can listen all the music from the internet in my room with decent result.
Are you sure about that? I thought a good 3.5mm connection would be miles better (assuming the source device has a decent DAC)
The real secret in my opinion though is the old Chromecast Audio. It has no microphone and is super tiny and only has a 3.5mm output (DAC is not amazing but also not bad). But the best kept secret is that the 3.5mm also can act as a mini TOSLINK (optical). I have mine connected to an old (but still very high quality) Yamaha receiver via mini toslink to regular toslink cable and set the quality to the highest settings. Music sounds amazing with full 5.1 channel large speakers. And I have a second chromecast audio in a different room that is in a "group" with the first which allows you to perfectly sync music in both rooms (basically ghetto Sonos). Goodluck doing that with bluetooth.
Best part is though that once you start the stream you can turn your phone off (or whatever device that started it) because the chromecast audio then goes directly to the internet. Nothing is actually streaming from the phone anymore.
> aptX and aptX HD codecs are proprietary to Qualcomm, so OEMs would previously acquire them directly from them.
It's not enough Qualcomm try to get parasitic fees for existing free codecs (they tried attacking Opus I think), they also want to charge for their own NIH ones? How Qualcomm like.
Point is, those codecs don't need to exist. What can they do that free ones can't? But since some might actually make such exact conclusion, Qualcomm try to go after free ones as a classic racketeer.
Well, I don’t know anything about these codecs but the article says that they are widely recognized as superior. Are you countering that?
If they are superior and some people are willing to pay for that, I guess that is why they exist. Charging for them seems perfectly fine as long as they are not abusively using some form of leverage to do so.
Giving away the encoder side seems smart but it also seems to indicate that the demand is not great enough for them to easily monetize both sides. It may all go Open Source eventually.
AptX and its HD version (which is basically the same algorithm configured with a different set of parameters) are very simple compared to e.g. AAC. If I remember correctly, aptX was initially designed as a computationally efficient ADPCM-based telephony codec. It still is, but it's being marketed as "audiophile-grade" nowadays. As to why it's still popular: SBC was indeed suffering from unnecessarily low bitrates and noticeable low-pass filtering, so aptX did sound nicer than many SBC implementations. But I guess "sounds better than broken SBC" doesn't sell as much as "indistinguishable* from high resolution audio".
But the one freaking thing I cannot understand is why after almost 20 years of wireless audio in computers, the microphone quality is still atrocious.
Anyway, I know the next version of Bluetooth will fix it.