[LG V20 ROMs, Kernels, Recoveries, & Other Developm] Omar-Avelar:
Low volume in Lineage 14.1 (at the moment you tested it) does not imply that the DAC is not being used. The tasha XML's configuration could have had less gain on the versions and could correspond to different volume levels than what stock uses since the xml's for the audio path..

Now, I want to share the Kernel analysis of the DAC code for the V20. Because as far as I can tell LineageOS Kernel is using the HiFi DAC under correct conditions.

https://github.com/oxavelar/V20-Kernel-Gamma/blob/integration/sound/soc/codecs/es9218.c

Let's start with the following information:

/* ES9812's Power state	/ mode control signals
reset_gpio;	//HIFI_RESET_N
power_gpio;	//HIFI_LDO_SW
hph_switch_gpio;	//HIFI_MODE2
reset_gpio=H && hph_switch_gpio=L	--> HiFi mode
reset_gpio=L && hph_switch_gpio=H	--> Bypass mode
reset_gpio=L && hph_switch_gpio=L	--> Shutdown mode
*/

So one can toggle HiFi to be activated if we do in theory:

reset_gpio=H && hph_switch_gpio=L	--> HiFi mode

That means that es9218_power_gpio_L() and es9218_hph_switch_gpio_H() must be called at a minimum.

Now if you take a look at : es9218_sabre_amp_start() the HiFi DAC will kick in according to impedance detection:

es9218_sabre_lpb2hifione() // Is when a load less than 50 Ohms is connected
es9218_sabre_lpb2hifitwo() // is for 50 Ohm impedance headphones
es9218_sabre_lpb2hifitwo() // Is when headphones higher than 600 Ohms are connected

lp stands for lowpower or what ESS calls shutdown mode.

Now if you check es9218_sabre_lpb2hifione() and es9218_sabre_lpb2hifitwo() this function will do what we mentioned in the beginning regarding the GPIO toggling and extra programming given by ESS, you guys can read it if you want, but I find the following is the most interesting part:

es9218_write_reg(g_es9218_priv->i2c_client, ESS9218_AMP_CONFIG, 0x03); //AMP MODE HiFi2, Enable HiFi but partially blocked by overrides

And more details are in the following portions:

/* Power down when headphone is plugged out. This state is the same as system power-up state. */
static int __es9218_sabre_headphone_off(void)

/* Power up to bypass mode when headphone is plugged in
Sabre DAC (ES9218) is still in power-down mode, but switch is on and sw position is at AUX/QC_CODEC.
Thus, i2c link will not function as HiFi_RESET_N is still '0'.
*/
static int __es9218_sabre_headphone_on(void)

So the moment a headphone is connected, it basically toggles the DAC on from bypass according to measurements in data.

The fun part is that if you look at the dmesg you can chase the following when you plug-in a headset!, whoever has high impedance headphones (between 50 - 600 Ohms, OR higher than 600 Ohms) can hunt for the following log

pr_info("%s() : state = %s , is_amp_on = %d \n",	__func__, power_state[es9218_power_state], es9218_is_amp_on);
es9218_sabre_bypass2hifi();

In summary, theory says that the following happens

es9218_sabre_headphone_on()
__es9218_sabre_headphone_on()
es9218_sabre_bypass2hifi()
:
registers write for DAC to configure
:
es9218_set_thd()
es9218_sabre_amp_start()

And another interesting part is the following file

https://github.com/oxavelar/V20-Kernel-Gamma/blob/integration/sound/soc/codecs/wcd-mbhc-v2.c

Which is where the impedance detection is handled and ends up calling es9218_sabre_headphone_on() and performs calculations with wcd_mbhc_get_impedance()

And everything gets controlled by the following

extern bool enable_es9218p;

Variable which is defined by

https://github.com/oxavelar/V20-Kernel-Gamma/blob/integration/kernel/sound/soc/msm/msm8996.c

#ifdef CONFIG_MACH_MSM8996_ELSA
bool enable_es9218p = true;
#else
bool enable_es9218p = false;
#endif

So every bit in the V20 Kernel points that when using the correct impedance you would be using the HiFi DAC (or have it activated). Now remember that the HiFi DAC is only used with headphones. And another interesting data point is that as [MENTION=8263672]toastyp[/MENTION] says, the Android subsystem must be aware of offloading the audio to the DAC (interesting read here).

Which in theory is also happening with LineageOS by having:

Which are what LG music applications must be doing in stock, they must be offloading the processing to the DAC only on the applications they want under the conditions they choose.

AFAIK LIneageOS already sets both of the offloading to true if you look at https://github.com/LineageOS/android_device_lge_msm8996-common/blob/lineage-15.1/system.prop...