bluez-alsa
bluez-alsa copied to clipboard
LHDC support
There are both decoder and encoder ARM libraries for AOSP. AFAIK they work for V2, V3 and V4. There's also AOSP 12.1 repo with V5, but libraries are not there.
The variants of liblhdc.so
distributed from Savitech in the repositories you have linked are only compiled for armv7 and armv8, which would create limitations on where this can be used.
One could always reverse engineer them or simply use QEMU
Reverse engineering should theoretically not be difficult—the libraries are compiled without stripping their debugging symbols. I have worked with calling ARM libraries through QEMU, but it is not a great solution in my opinion.
https://gitlab.com/savitech-lhdc/savitech-lhdc-codec-aosp-12.1.0r1/-/blob/lhdc_aosp_1210r1_main/external/liblhdc/src/lhdcBT_enc.c
https://gitlab.com/savitech-lhdc/savitech-lhdc-codec-aosp-12.1.0r1/-/blob/lhdc_aosp_1210r1_main/external/liblhdcdec/src/lhdcBT_dec.c
https://gitlab.com/savitech-lhdc/savitech-lhdc-codec-aosp-12.1.0r1/-/blob/lhdc_aosp_1210r1_main/external/liblhdcv5/src/lhdcv5BT_enc.c
https://gitlab.com/savitech-lhdc/savitech-lhdc-codec-aosp-12.1.0r1/-/blob/lhdc_aosp_1210r1_main/external/liblhdcv5dec/src/lhdcv5BT_dec.c
This seems to be the source code? no reverse engineer is required.
UPD: sorry, I didn't realize that the core components are in the .so
binary.
u want this ?
@zhubinsheng that's an old version, I've already got latest v2/3/4 and v5 libs from 1+11 and slowly reverse engineering them. I haven't yet touched v5 as there's certainly a newer version (according to gitlab), but it wasn't used by any smartphone manufacturers.
@arkq I have reverse engineered LHDC encoder library. I don't want to publish poorly tested code (and I'm sure it's broken at least in some cases), so will hold off the release untill I'll have more confidence in the correctness. Currently my library supports 2/3/4 encoding and exposes same API as library from gitlab, some "Extra API" functions are stubs (mostly AR; JAS and META should work, but they don't seem to do much anyway). AR is not supported and probably never will be. It would be easier to just directly use SAF for Spatial Audio (which is what I would've done if I've ever wanted to get feature-complete liblhdc). ~~LLAC is currently not supported.~~ It works, but quality is much worse than original library. This is under investigation currently. Decoding of versions 2/3/4 will probably be supported later. LLAC decoding should work already, but API is very different from liblhdcBT_dec.so