ALC294: Internal speaker + 3.5mm jack fix for ASUS UX6404VI/VV (1043:1863)

On my Asus Zenbook Pro 14 OLED (UX6404VI, ALC294, subsystem ID
1043:1863), the headphones jack was completely silent and the internal
speakers would mute themselves after ~2 seconds of audio playback.
Setting bit 10 (0x0400) of undocumented Realtek vendor coefficient
0x1b on NID 0x20 solves both problems by enabling analog output (and
apparently keeping the HDA link bit-clock running which Claude thinks
is why the amps of the internal speakers mute themselves ~2 seconds
into playback, but I don't fully understand that part myself, but
setting the bit makes the speakers work correctly throughout
continuous playback).

Just to be clear, the issue with this audio chip is with this
undocumented bit. Everything in standard HDA space is good, pin 0x21
config, EAPD, amp mutes, DAC routing and SOF gains are all correct,
and it stays silent with SOF bypassed via snd_intel_dspcfg
dsp_driver=1 and raw speaker-test. It is also not a recent regression,
I tested on kernal 6.18-lts without any luck.

I found this bit by capturing the COEF registers as Linux sets them as
a baseline, rebooting to Windows, while playing audio off the working
headphones jack I BSODed the system with NotMyFault (a clean restart
without a BSOD would clear the bits), warm-booted from there into
Linux with `snd_hda_intel probe_only=1` to prevent Linux from changing
the COEF registers, diffed the registers with the Linux ones as a
baseline, and played with setting them manually until I found the
minimum change needed to produce audio. On a clean boot, turning this
one bit on fixes the audio and turning it off breaks it again. I was
originally trying to fix only the audio jack (had given up on internal
speakers long ago), but I found after fixing it that the same bit also
fixes the internal speakers as well.

I set this up to run at boot, and now my audio system works:
```
BIT=0x0400
IDX=0x1b
C=""
for h in /dev/snd/hwC*D*; do
  n="${h##*hwC}"; card="${n%%D*}"; dev="${n##*D}"
  if grep -qi '0x10ec' "/proc/asound/card$card/codec#$dev"
2>/dev/null; then C="$h"; break; fi
done
[ -z "$C" ] && { echo "alc294-hp-fix: no Realtek codec found" >&2; exit 1; }
hda-verb "$C" 0x20 SET_COEF_INDEX $IDX >/dev/null 2>&1
cur=$(hda-verb "$C" 0x20 GET_PROC_COEF 0 2>/dev/null | grep -oE
'0x[0-9a-f]+$' | tail -1)
[ -z "$cur" ] && { echo "alc294-hp-fix: could not read COEF $IDX" >&2; exit 1; }
new=$(printf '0x%04x' $(( cur | BIT )))
hda-verb "$C" 0x20 SET_COEF_INDEX $IDX >/dev/null 2>&1
hda-verb "$C" 0x20 SET_PROC_COEF $new >/dev/null 2>&1
hda-verb "$C" 0x20 SET_COEF_INDEX $IDX >/dev/null 2>&1
chk=$(hda-verb "$C" 0x20 GET_PROC_COEF 0 2>/dev/null | grep -oE
'0x[0-9a-f]+$' | tail -1)
```


Hardware:
  Model:        ASUS Zenbook Pro 14 OLED UX6404VI (board UX6404VI)
  BIOS:         UX6404VI.304, 11/02/2023
  Codec:        Realtek ALC294
                Vendor Id     0x10ec0294
                Subsystem Id  0x10431863
                Revision Id   0x100004
  Controller:   Intel Raptor Lake-P/U/H cAVS [8086:51ca] rev 01 (0000:00:1f.3)
  Amps:         2x Cirrus Logic CS35L41 on SPI
(spi1-CSC3551:00-cs35l41-hda.0/.1)
  Driver:       SOF, sof-audio-pci-intel-tgl
                machine driver  skl_hda_dsp_generic
                firmware        sof-rpl.ri
                topology        sof-hda-generic-4ch.tplg
  Kernel:       7.1.5-arch1-2 (x86_64), Arch Linux

This is my first time reporting a bug in this method and my
understanding of most of this is vague, if I need to send anything
else let me know.

Thanks,
Hezekiah Depp