Showing results for 
Search instead for 
Did you mean: 

ROG Phone 8 - Bluetooth aptX Adaptive seems hardcoded to 24-bit only

Star III

Neither the Developer Options nor the 3rd party Bluetooth Codec Changer app lets me select 16-bit. This makes me concerned that ASUS has hardcoded it to 24-bit in the AOSP build and that this action might prevent the phone from ever going into aptX Adaptive’s lossless mode which operates only at 16-bit.

The developer options depicts the 16-bit greyed-out as though it can’t ever operate in 16-bit due to build configuration.

This could all be normal because lossless mode comes with no UI visual aids to let you know it’s in operation. I wish there was an option to display the realtime BT bit rate at the top of the screen and then we’d be able to see when it hits 1Mbps or higher.


I’ve contacted support and they’ve escalated to HQ.



Hi @AndrewMcN 
Could you please upload a picture of the setting?

Developer OptionsDeveloper Options


Bluetooth Codec ChangerBluetooth Codec Changer


Star III

I captured the system logs whilst connecting my QCC3081 ear hooks. The system recognises they are capable of aptX Adaptive v2.2 (aptX Lossless capable). I then played a 16-bit 44.1kHz lossless track from Apple Music.

You can see that the system recognises the audio I am playing back is a 16-bit source but the codec config appears to continue to stay at 24-bit. In fact, it's saying it's just using aptX Adaptive v2.1 (which is the version before aptX Lossless). This tells me that aptX Lossless is not working in the current firmware.

The issue may be in the source file as this has all the aptX Adaptive codec config with just "BTAV_A2DP_CODEC_BITS_PER_SAMPLE_24". The R2.2 entries perhaps also need the line "BTAV_A2DP_CODEC_BITS_PER_SAMPLE_16" but I'm not an Android programmer and only guessing. I can see use of this in someone else's published version of this file on Github. Again, Qualcomm's documentation or Customer Engineering team should be able to provide help. Page 52 of the "Qualcomm aptX User Guide" discusses how to debug this.

Here is a file with all the logging I captured in it, that the developers would know how to read: 

Star III


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.