thank you Linux for giving a damn about Bluetooth headphones
For context, LDAC is one of the few wireless audio codecs stamped Hi-Res by the Japan Audio Society and its encoder is open source since Android 8, so you can see just how long Windows is sleeping on this. I'm excited about the incoming next gen called LC3plus, my next pair is definitely gonna have that.
For context, LDAC is one of the few wireless audio codecs stamped Hi-Res by the Japan Audio Society and its encoder is open source since Android 8
LDAC is great, but simply stating that the encoder is "open source" is quite misleading (while technically correct). The codec is owned by Sony and heavily licensed. It's a savvy business move of Sony to make the encoder free to use though, so everyone else can support their standard while charging manufacturers who want to integrate it into their headphones.
If we want a really free and open high quality codec, we should push for opus support via bluetooth
Not anything to do with the LDAC codec but why does wireless headphones on windows suck. On linux (even a wm) I just turn on my headphones and it works, on windows every time I have to remove the device and add it back again
Man, Anker makes the best price for performance headphones in my opinion. I have the Life 2 Neos and love the sound quality and battery life. They can take a beating too as I used to wear them doing blue collar work so they've taken a few nice hits and still work fine.
Sony did drop the ball with LDAC quite quickly, it could've been the new standard.
But with the release of the WH-1000XM3s (or was it the 4s?) they basically made most of the selling points incompatible with LDAC, so now almost no one uses it anymore.
Ldac is not actually that good, it's actually fairly rare that LDAC beats out something like SBC XQ let alone AAC
EDIT: for elaboration, LDAC works at 3 main data rate ranges 990/909, 660/606 and 330/303. Ldac is only high res at the 990 range, and even at that range, it still often looses when pipewire is compiled against libfdk. keep in mind that it's hard to get real numbers on LDAC because decoding is proprietary, meaning I had to disassemble headphones and connect those for verification, but typically AAC on supported headphones beat out 990kbps LDAC (which is hilarious btw considering LDAC can rarely actually work at 990kbps anyways) and both SBC-XQ and LC3Plus (both of which are usable with pipewire) regularly beat 660kbps LDAC.
TLDR LDAC is crap and SBC-XQ is typically more accurate and lower latency, and LC3Plus is even better then that. and if you have AAC compatible headphones assuming latency isnt a major issue (which you are using LDAC so it's not) just use AAC, both fidelity and latency is better
EDIT: I should mention, it is known that vendors will tune codecs, I believe Valdikks article in habr briefly goes over this. so it's very possible that tuning could mean that x codec, including LDAC could be the only good codec, however with how badly LDAC maintains 990kbps, I doubt it will make much of a difference
LC3plus is worse than AAC quality wise (to be expected). Lower latency is the only thing going for it. And that's just because AAC is a very high-latency codec. Opus (as a format) would win on both fronts, although there could be issues with creating a high-quality encoder for it that is not too complex, and power-efficient.
Shame about headsets though - has anyone been able to get the mic to work without the audio quality dropping to trash? It is a shame to have to pick between good quality audio and the ability to use your mic.
Definitely. I have a pair of pixel buds that give me very noticeable latency when paired in Windows. I've never been able to find a way to use the low latency codecs to fix this.
In Linux it's a complete opposite experience. I have a menu with every codec in the book, and I can actually watch video in Linux without even noticing any latency now.
I have the exact same headphones hahaha, this is perfect how are you liking them by the way? I had some connection problems on the first month but this 2nd month they've been behaving good
Any way to see which bitrate is currently being used? I know you can set it to use only 909kbps, 606kbps or 303kbps in the wireplumber config, but I am curious which bitrate the adaptive mode (usually) uses.
I'd love to say the same but on my Lenovo laptop I get frequent disconnects with bluetooth earphones on Linux alone. Apparently it's a firmware problem with the AX200 board, but even after having updated the firmware and following all the online fixes I still have the problem.
My whole use case for my laptop is getting away from my desk when I want to read something and listen to music at the end of the day, but it's annoying to have to reconnect the earphones every 10 or so minutes. Like everything Linux, it's incredible as long as you have supported hardware and you don't bump into some weird edge case.
I definitely love it for the "it just works" (or rather, you have full control to make it work) factor!
I'm not familiar with the latest in BT audio, but isn't the standard still sub-par in that it has very limited overall frequency bandwidth, resulting in deep sacrifices to fidelity?
I recall a detailed analysis of different BT audio codecs a while back, and the spectrum analysis always showed relatively high noise floor and frequency roll-off (hi-cut/low-cut) within the threshold of human hearing (though admittedly close to the limits). Also, I recall (and this could just be the 2016 tech I am familiar with) that overall bandwidth was limited in that if you played something with low frequency tones, the upper frequencies were dropped, or vice versa. I used to confirm this by using a flat EQ setting, then boosting any range, and you could easily detect the loss of frequency response in the adjacent or distant ranges.