[LG V30 Questions & Answers] TheDannemand:
Oh yes, I remember.

First of all, several people have disputed gsmarena's measurements, one even claiming they must have had a defect V30 (as I recall) because their numbers don't match what others have measured. Head-fi titan csglinux (who, to his credit, disagrees with me calling him that) has posted lots of measurements there, which I trust more.

Second, that quote by ProtegeManiac (also far more knowledgeable than me) assumes that the QuadDAC is four independent DACs in series (or 2+2 in series+parallel) each with their own integrated OpAmp. This would be quite different from the Android Authority article, which describes four parallel DAC units, essentially multiplying their output current, followed by a separate amp unit converting that current into voltage (and of course adding further amplification as needed). This latter design makes more sense to me, and would not suffer stereo crosstalk issues as described. But again, I am not a DAC design expert by any means.

But even IF it is true that HIM increases stereo crosstalk, that only further stresses why people should stop chasing HIM when their headsets don't need it.

Afraid I am not the right person to comments on those: I almost entirely listen to music using fullsize cans (over-the-ear headphones) but I also don't use any Virtual Surround, DTS:X, EQ etc for music. Personally I am waiting to pick up the Monoprice M1060C Planar Magnetics for $200 on a sale -- knowing that they are about the size and weight of a pickup truck, and that they WILL require me to force HIM on my V30.

I haven't played with mixer_paths_tavil.xml myself, as I haven't had a need to force HIM.

But I think two things often get mixed up: Headset type and AVC settings.

As shown in the code snippet included in my earlier post, the driver chooses amplification mode based on the headset type value it receives. And those headset type values are defined in mixer_paths_tavil.xml as shown in the following code snippet from the driver:

static int es9218_headset_type_put(struct snd_kcontrol *kcontrol,
struct snd_ctl_elem_value *ucontrol)
{
int value = 0;

value = (int)ucontrol->value.integer.value[0];

if(value != 0) {
g_headset_type = value;
pr_debug("%s(): type = %d, state = %s\n ", __func__, value, power_state[es9218_power_state]);
} else {
/*
* In mixer_paths.xml, 0 stands for no headset.
** init ** : <ctl name="Es9018 HEADSET TYPE" value="0" />
* normal : <ctl name="Es9018 HEADSET TYPE" value="1" />
* advanced : <ctl name="Es9018 HEADSET TYPE" value="2" />
* aux : <ctl name="Es9018 HEADSET TYPE" value="3" />
*/
pr_err("%s() : invalid headset type = %d, state = %s\n", __func__, value, power_state[es9218_power_state]);
return 0;
}

if (es9218_power_state < ESS_PS_HIFI) {
pr_debug("%s() : invalid state = %s\n", __func__, power_state[es9218_power_state]);
return 0;
}

es9218_set_thd(g_es9218_priv->i2c_client, g_headset_type);
// es9218p_sabre_bypass2hifi(); // unnecessary code, but remain it as histroy.

return 0;
}

So different headset types specified in mixer_paths_tavil.xml should indeed affect the DAC amplification mode triggered by the driver.

In addition to that, AVC levels (Analog Volume Control) are specified in mixer_paths_tavil.xml as well. These do NOT change the amplification mode, just the level of amplification within a given mode (the specified AVC levels index a table in the driver).

As described earlier, Aux mode (>600ohm) is actually implemented as Hifi1 amp mode (1Vrms) combined with higher AVC settings than Normal mode (<50ohm).

So with different combinations of HEADSET TYPE and AVC VOLUME in mixer_paths_tavil.xml, one should be able to control the DAC's amp mode and AVC volume setting -- as has indeed been accomplished by the various mods.

Again, I have not played with those myself, I am merely interpreting the interaction between mixer_paths_tavil.xml and the ESS driver.