Having further studied Qualcomm's developer documentation, I can't seem to come to a better conclusion at the moment, other than to assume that this 24-bit-only configuration is normal for aptX Lossless. The documentation on lossless is very thin on the ground for those that are not actively producing smartphones. Qualcomm's description of how the achievement of lossless mode is monitored confirms this. They effectively say you need their QXDM product which has to be licensed from them or to capture packets at the receiving device and then confirm the configuration of those packets is that of lossless. Lastly, they say to contact their customer engineering team for further info.
So, for the moment, my conclusion is that lossless is something that happens with very little evidence that it's working and that it may be happening somehow encapsulated within the 24-bit codec operation.
They also talk about prerequisite conditions needing to be met, such as:
ASUS having enabled QHS (Qualcomm High Speed) which is not enabled by default and apparently can only be confirmed using QXDM.
Playback sources must be either 16-bit/44.1kHz or 16-bit/48kHz (48kHz is downsampled on Classic Bluetooth)
Codec must have (re)negotiated to 44.1kHz (for Classic Bluetooth)
Codec configuration must have aptX Adaptive in High Quality mode
Wi-Fi must be on a 5GHz network or deactivated - That means no 2.4GHz Wi-Fi supported on same device
Excellent link quality is required and this means the receiving device must not be more than 5 metres away with no obstacles in between. Best signal is within 1 metre.
Then even if all these conditions are met, you can only assume that lossless mode will kick-in and do its thing.
I did some basic log capture and spotted a couple of things that might mean lossless mode is likely happening:
aptxalsCodecConfig: SetAudioProfileHighQuality AUDIO_PROFILE_16_BIT_SOURCE
bt_btif : btif_update_source_codec: Aptx Adaptive mode = 20480, codec_latency = 700
These two log entries seemed to go hand-in-hand, suggesting that aptX Adaptive mode 20480 might indicate what they call "scale-to-lossless" where the Bluetooth bandwidth is ramped up to 1.2Mbps. When playing back non-16-bit sources, the aptX Adaptive mode log entry shows 4096 instead of 20480.
Also, the part where the codec may need to be in 44.1kHz sample rate configuration may be unreliable. I found that when switching between different sources with different sample rates, the codec was not always reconfigured to 44.1kHz. For me, it stayed on 96kHz. So, in this scenario, does it mean lossless cannot be achieved? A workaround to this issue may be to use the Bluetooth Codec Changer app's beta ability to switch sampling rates for us. When using this, I saw more of the two aforementioned log entries. Unfortunately, this feature can cause a brief audio dropout during the sample rate change.
It's a shame that it has to be this complicated. I can only assume that they chose not to have a UI display stating whether lossless is achieved because the transmission may so easily be knocked out of the list of prerequisites. I'm also wondering just how vulnerable it is to the mere presence of 2.4GHz Wi-Fi signals. Interference may be the main reason.
What would be handy, would be the ability to display the realtime Bluetooth bit rate at the top of the screen. Apparently, this isn't possible through installing an app as it requires root. So, perhaps it's something ASUS might be able to engineer into its build. We can then monitor this for it achieving between 1.0 and 1.2Mbps.
