MichaIng

schedutil is my default governor, where I recognised the issue first. Tested several times, same like with ondemand the little cores stay at 100 MHz during tmpfs file read and write. Also I'm not sure whether it triggers on I/O alone, as has no option for this like ondemand.

Many thanks for this. I played a bit more around with these and found the following logic:
With TOACODEC OUT EN and TOHDMITX one can enable analogue 3.5mm output and digital HDMI output. With TOACODEC SRC resp. TOHDMITX I2S SRC one can select the I2S device used for 3.5mm output respectively HDMI output. I cannot get I2S A working (because there is no TDMOUT_A at all), but I2S B and I2S C work for both HDMI and 3.5mm each. I assign it like you did, I2S B to TOHDMITX I2S SRC and I2S C to TOACODEC SRC. Now, with TDMOUT_B SRC SLT resp. TDMOUT_C SRC SLT one can assign I2S B resp. I2S C to an ALSA device, i.e. which one will be hw:0,0, hw;0,1 or hw:0,2. Since there is no TDMOUT_A, I cannot assign I2S A to any ALSA device. I set TDMOUT_B SRC SLT (HDMI) to IN 0 (device 0) and TDMOUT_C SRC SLT to IN 1 (device 1). FRDDR_[ABC] SRC [123] EN needs to additionally enable the I2S sources on the ALSA device, but somehow it is associated in a confusing way: FRDDR_A is related to ALSA device 0, FRDDR_B to ALSA device 1 etc, SRC 1 is related to I2S A, SRC 2 to I2C B etc. Would have been easier to understand when those would be named FRDDR_[012] SRC [ABC] so that device index and I2C identifier match. However, hence I need to enable FRDDR_A SRC 2 and FRDDR_B SRC 3, matching the TDMOUT_[BC] SRC SLT assignments above. Finally I think its the output channels which need to be split for the used ALSA devices, FRDDR_[ABC] SINK [123] SEL. Basically, at least when all channels are used, the three sinks for the used ALSA devices need to be split. With my 2.0/2.1 test audio hardware I just use OUT 0, OUT 1 resp. OUT 2 for each FRDDR_[AB] SINK 1, 2 resp. 3. All other controls seem to have no effect in my case, I guess its about SPDIF input and assigning capture devices/microphones, as of TODDR (to) and FRDDR (from) hence to which audio device input is sent compared what we assigned from which audio device the stream is received and sent to which sinks/channels, or so.

I first used Kingston endurance SD card with Armbian Buster image. This failed due some incompability with Odroid N2 UHS implementation, but Sandisk extreme SD card worked with same image.
After successful boot runned nand-sata-install to ADATA SP 550NS38 SSD connected using VL817 SATA Adaptor (2109:0715).
Upgraded the Debian to Bullseye and installed Mesa 21.2.0 packages from experimental repositories, arm64 firefox-esr and armhf Chromium via multiarch to use widevine extracted from ChromeOS images (local err.ee web broadcasts some programs with widevine encryption). This was in the end of august. It mostly worked, but had 3 weird problems that I think to have solved now having some free time.
 
The USB boot hanged up about half of times after kernel detected the SATA drive. Turns out that UAS is culprit, disabling UAS with usb-storage.quirks=2109:0715:u made it now boot every time without problems (modified /boot/boot.ini). About 2-3 minutes after boot the compositor froze (no matter which - tried Xorg compton, wayland Weston and Wayfire (self compiled). Turns out armbian has /etc/udev/rules.d/hdmi.rules which runs /usr/local/bin/hdmi-hotplug. For some reason the hdmi-hotplug script stalls on my Odroid installation and when systemd finally killed it, something went wrong and the compositors froze. Diverting the hdmi.rules fixed it. This was/is weirdest - when TV connected via HDMI was off and turned on, then sometimes the board would shutdown. Found from auth log "auth.log.1:Dec 25 19:04:59 piix systemd-logind[1641]: Power key pressed." Like WTF, i don't have any "power key" and why it gets invoked when TV is turned on. Set the *Key=ignore in /etc/systemd/logind.conf and it seems fine now, no idea what went wrong there. The kernel even don't have CEC enabled (CONFIG_CEC_MESON_AO and CONFIG_CEC_MESON_G12A_AO are not set for some reason in the armbian kernels).  
A bit later I also saw 5.15.8-meson64 kernel OOPS "Unable to handle kernel execute from non-executable memory" at regmap_update_bits_base+0x74/0x98, meson_clk_cpu_dyndiv_set_rate+0xf4/0x118. As I hadn't seen this before, downgraded to 5.13.12-meson64. I plan to report the OOPS with full kernel dmesg output, when I'll have a bit more time (probably the https://bugzilla.kernel.org/ would be right place?).
 
Currently it seems to work fine, with the 5.13.12-meson64 kernel and mesa/panfrost 21.2.1-2 (from snapshot.debian.org). Weston is used as Wayland compositor. It is important to note that I have 1080p TV, and all video decoding is done on CPU without using the Amlogic VPU acceleration, as the VPU driver is currently both broken in the kernel and unsupported in unpatched userspace. I expected this when choosing the board. Fortunately the 4xA73@2.4GHz is fast enough for decoding most 1080p videos and panfrost is fine for doing the video output after decoding. AFAIK playing 4K videos is currently not possible on Odroid N2 with mainline kernel and the vendors proprietary VPU decoder isn't supported by any software in open source distributions like Debian. Interesting is that Firefox seems to handle the video decoding pathway better for Youtube in this configuration,
while Chromium occasionally stutters on some Youtube videos, these seem to be fine with Firefox. Luckily this seems to not affect the site where I needed widevine (that works only with Chromium in practice). In september widevine upgraded to version needing patched libc. I got patched armhf libc6 package from apt.xbian.org repository.
 
The ALSA configuration is weird, amixer scontrols | wc gives 50 controls, and if misconfigured, then the thing doesn't give any audio output. I found the following script from somewhere that "fixes" it into working state:
 
amixer sset 'FRDDR_A SINK 1 SEL' 'OUT 1' amixer sset 'FRDDR_A SRC 1 EN' 'on' amixer sset 'TDMOUT_B SRC SEL' 'IN 0' amixer sset 'TOHDMITX I2S SRC' 'I2S B' amixer sset 'TOHDMITX' 'on' amixer sset 'FRDDR_B SINK 1 SEL' 'OUT 2' amixer sset 'FRDDR_B SRC 1 EN' 'on' amixer sset 'TDMOUT_C SRC SEL' 'IN 1' amixer sset 'TOACODEC SRC' 'I2S C' amixer sset 'TOACODEC OUT EN' 'on' amixer sset 'TOACODEC Lane Select' '0' amixer sset 'ACODEC' '255' amixer sset 'FRDDR_C SINK 1 SEL' 'OUT 3' amixer sset 'FRDDR_C SRC 1 EN' 'on' amixer sset 'SPDIFOUT SRC SEL' 'IN 2'  
After that ALSA pcm "hw:0,1" output works. I configured dmixed and removed pulseaudio, as it seemed to complicate things with no benefit when mpc and browser run as different users.
 
Armbian is great (couldn't have the board working so well without armbian) and merry holidays for you
Hoping this helps others having Odroid N2(+) board.

I can now confirm that HDMI audio is up for me. I am still on my NanoPC-T4 MicroSD card but it was only necessary to insert appropriate Odroid-N2+ configurations.
 
I used the settings from here.

I have two questions regarding mainline (5.10.x) kernel on Odroid N2(+), hope it is fine to ask them here:
It is expected that the boot.ini contains legacy kernel command-line parameters, which are not supported by mainline kernel anymore, including HDMI settings, HPD, overscan, CPU count and clock, right? I saw https://github.com/armbian/build/pull/2629 but the CPU frequency settings are still/again ignored, the CPU always runs at highest possible frequencies. However, it is not a big issue since min/max frequencies can be easily set via CPUFreq API. Interestingly, when using display_autodetect "true", hdmimode "custombuilt" and modeline are set and "hdmitx edid" seems to create two related files in /boot, but all without effect, it seems? I did RAM R/W benchmarks by writing and reading back a ~2 GiB file to /tmp (tmpfs) and evicting filesystem cache between both steps (sync; echo 3 > /proc/sys/vm/drop_caches), via dd (+conv=fdatasync on write step) which reports back the read/write speeds. Somehow with Linux 4.9 provided by Hardkernel (e.g. with the image provided by Meveric here: https://oph.mdrjr.net/meveric/images/Buster/), I get ~doubled speeds, compared to Armbian Linux 5.10 (reproducible, with nice -19, no other significant processes running etc). I have not yet tested the Armbian image with legacy kernel, but has anyone an idea what the reason could be, or whether the benchmark method is faulty for some reason?

Great fixes @MichaIng code is deployed.  Thank you so much!

I would say same script, but changing the list to not include scheme, and then prepend scheme of client request to target mirror: https://github.com/armbian/dl-router/blob/master/app/mirrors.yaml
I also see that mirrors.netix.net entry is with HTTP, but it has forced redirect to HTTPS, at least after receiving the HSTS header once.
 
I'm learning Python by doing little contributions here and there, so I'll have a look if I can add this feature :).

I created a pull request: https://github.com/armbian/dl-router/pull/14

Could the issue be that every single file can be pulled from a different mirror? E.g. when packages list is pulled form one mirror, the content hashes from another one and the final package again from another one, it is easily possible that one does not match as for sure not all mirrors sync and have caches emptied exactly the same time. E.g. here my apt update which pulls from various different mirrors:
Get:5 https://minio.k-space.ee/armbian/apt buster InRelease [18.3 kB] Get:6 https://minio.k-space.ee/armbian/apt buster/main armhf Packages [591 kB] Ign:6 https://minio.k-space.ee/armbian/apt buster/main armhf Packages Get:7 https://minio.k-space.ee/armbian/apt buster/main arm64 Packages [698 kB] Ign:7 https://minio.k-space.ee/armbian/apt buster/main arm64 Packages Ign:7 https://apt.armbian.com buster/main arm64 Packages Ign:7 https://apt.armbian.com buster/main arm64 Packages Get:8 https://minio.k-space.ee/armbian/apt buster/main arm64 Contents (deb) [11.2 MB] Ign:8 https://minio.k-space.ee/armbian/apt buster/main arm64 Contents (deb) Get:9 https://minio.k-space.ee/armbian/apt buster/main armhf Contents (deb) [17.3 MB] Ign:9 https://minio.k-space.ee/armbian/apt buster/main armhf Contents (deb) Get:6 https://us.mirrors.fossho.st/armbian/apt buster/main armhf Packages [591 kB] Err:6 https://us.mirrors.fossho.st/armbian/apt buster/main armhf Packages   File has unexpected size (591174 != 590754). Mirror sync in progress? [IP: 23.237.182.68 443]   Hashes of expected file:    - Filesize:590754 [weak]    - SHA512:bb903949666449552cda361ee24d4d0579baa72915b5fb3d7418acede319562ce4b93a15bf7605ae270bd9f0e59ececf622fea1365e8aa7a3d8339e2a2644f56    - SHA256:d822f1c4a63ce566baa27d1f5c523057c1d295222f097b072dc8fbeb14a29bc3    - SHA1:0f37871329a6a28cf7c53dd6ffd952342432c7ed [weak]    - MD5Sum:517fa48fb23e17f6c94248da6ce5b44b [weak]   Release file created at: Sat, 12 Dec 2020 15:07:27 +0000 Get:7 https://armbian.systemonachip.net/apt buster/main arm64 Packages [3941 kB] Err:7 https://armbian.systemonachip.net/apt buster/main arm64 Packages Get:8 https://mirrors.dotsrc.org/armbian-apt buster/main arm64 Contents (deb) [11.2 MB] Err:8 https://mirrors.dotsrc.org/armbian-apt buster/main arm64 Contents (deb) Get:9 https://armbian.tnahosting.net/apt buster/main armhf Contents (deb) [17.3 MB] Err:9 https://armbian.tnahosting.net/apt buster/main armhf Contents (deb) Fetched 18.3 kB in 55s (332 B/s) Reading package lists... Done E: Failed to fetch https://us.mirrors.fossho.st/armbian/apt/dists/buster/main/binary-armhf/Packages.bz2  File has unexpected size (591174 != 590754). Mirror sync in progress? [IP: 23.237.182.68 443]    Hashes of expected file:     - Filesize:590754 [weak]     - SHA512:bb903949666449552cda361ee24d4d0579baa72915b5fb3d7418acede319562ce4b93a15bf7605ae270bd9f0e59ececf622fea1365e8aa7a3d8339e2a2644f56     - SHA256:d822f1c4a63ce566baa27d1f5c523057c1d295222f097b072dc8fbeb14a29bc3     - SHA1:0f37871329a6a28cf7c53dd6ffd952342432c7ed [weak]     - MD5Sum:517fa48fb23e17f6c94248da6ce5b44b [weak]    Release file created at: Sat, 12 Dec 2020 15:07:27 +0000 E: Failed to fetch https://armbian.systemonachip.net/apt/dists/buster/main/binary-arm64/Packages E: Failed to fetch https://mirrors.dotsrc.org/armbian-apt/dists/buster/main/Contents-arm64.gz E: Failed to fetch https://armbian.tnahosting.net/apt/dists/buster/main/Contents-armhf.gz E: Some index files failed to download. They have been ignored, or old ones used instead. The reported successful update from @dispo above was one case where everything was pulled from the same mirrors.netix.net mirror.

I'm not sure how e.g. Debian handles this, but it makes IMO sense that somehow tie a client to a fixed mirror for a certain time.

Although I just compared the files of three mirrors and they all match, synced at 15-Dec-2020 09:03. So not sure if this really is the issue.