Qualcomm has open sourced its aptX and aptX HD encoders
old.reddit.com
old.reddit.com
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.
I knew that back in the time of bluetooth 2.0. Sadly it didn't... especially not the high quality stereo audio + microphone at the same time.
Also have abused way too many people through way too many versions of Bluetooth.
> 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
[1] https://old.reddit.com/r/Android/comments/11t16lk/qualcomm_h...
Cellphone audio is transmitted at some ridiculously low bitrate (8k?).
AirPods, and probably other Bluetooth headphones, reduce the audio output quality when the mic is on. This is to save on battery life.
And yet people are still not satisfied with the "great battery life" . They want "audio quality". In a speaker the size of a grain. /s
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.
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.
A very long time ago, they used buffers.
Open source != free to use anywhere. (In this case)
This is the way. And while you may not be legally entitled to, you can.
Examples like these make it clear why FSF explicitly distances itself from the term open source.
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).
Right now everything you listened to on wireless are being re-encoded and decided on the fly.
As you can see, no one that isn't forced to has any interest in aptX.
Someone (everyone?) in the BT consortium makes/made additional money from using something proprietary.
Otherwise BT would just support Opus for many years already.
If there is interference or the receiver is far (both means the signal/noise ratio is lowered), the quality is lowered to require less bandwidth.
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.
... 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?!
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.
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.
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"
– LLAC/LHDC LL: 30ms[2].
– BLE LC3: 7.5ms[3].
– BLE LC3Plus: 5ms[3].
[1] https://www.aptx.com/aptx-low-latency
[2] https://www.soundguys.com/understanding-bluetooth-codecs-153...
[3] https://www.iis.fraunhofer.de/en/ff/amm/communication/lc3.ht...
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.
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.
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")
I was really hoping to see more handset and headset supporting it, but its news seem to have fizzled out.
Anyone in the industry is able to share news there? Do we just need to wait? Is it encumbered in patents or too expensive to implement?
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.
P.S. there is! https://hydrogenaud.io/index.php/topic,114566.msg1023511.htm...
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.
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.
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 was made in the 80s
Opus came out in 2012
Someone had to pay money to make them exist… because no one was making free ones!