JMCC

Regarding the lack of support for NVMe/SATA, I think it is as simple as the fact that the SoC doesn't seem to support them. Amlogic aims to release SoC's that are just enough for a standard TV box, they don't have things such as Chromebooks in mind when they design their SoC's (as, for example, Rockchip does for their higher-end SoC's). And that is the reason why we can buy this board much cheaper than any equivalent RK3399. Here you trade brute horsepower for extra features in the SoC.
 
[UPDATE]: Even though PCIe was never mentioned in the official announcements of S922X (see, for example here and here),  recently someone pointed out that they got a "leak" from Amlogic saying otherwise. According to that "leak", the SoC would have a single-lane PCIe interface, but it is pin muxed with USB3. In other words, you would need to disable USB3 in order to use PCIe, and that would still be single-lane.
 
Definitely, disabling USB3 in favor of a possible SATA/NVMe interface would be IMO a very bad choice for a general-purpose board. Maybe if they release in the future something like the HC1, based on S922X, it could make sense. However, given the fact that Amlogic has not officialy announced that PCIe support, and after the "fiasco" with the broken PCIe in Allwinner H6, I won't believe that these are real options for this SoC until I see it actually working.
 
You can find the whole discussion about the matter in this page from CNXSoft

It looks like you weren't running the install script from the script's folder, but from some other directory. You must untar the tarball, cd into the created "media-script" directory, and run "./media-s905.sh"

Well, no fancy introduction here, because this doesn't pretend to be a script for the general use, only for testers who want to try the current *very early* status of the media capabilities in the Armbian meson mainline kernel.
 
Warning: It will replace your current kernel with a pre-compiled nightly 4.19.20.
 
Instructions:
Download, untar and run. If you need further instructions, then you are not ready for this script (again, it is very unpolished, not for general use).
 
Download link: https://mega.nz/#!YvYUhayC!CI1fl52V4tV0G4oqUib4W-NlMpVSpLDp8kmo74g-V08
 
Things that you can try with this script, on a X session:
 
Use a 1080p@30fps h264 video, and play it with "mpv -hwdec <filename>". You'll see in the logs that it is decoding through v4l-m2mcopy Install and run glmark2-es2 Use Chromium WebGL Play a 1080p@30fps video in YouTube in full-screen smoothly. I'm pretty sure it is not really using HW decoding as it claims (there is no  initialization message in dmesg), but it's smooth for sure.  
Gstreamer is tested not to work, in some other forum I was told that Bionic version is not enough and I need to compile a newer one.
 
Performance is not in any way good, but it is a starting point. Anyway, the first TO-DO is getting the mali module integrated into the kernel, so there is no need to compile it separately.

Well, no fancy introduction here, because this doesn't pretend to be a script for the general use, only for testers who want to try the current *very early* status of the media capabilities in the Armbian meson mainline kernel.
 
Warning: It will replace your current kernel with a pre-compiled nightly 4.19.20.
 
Instructions:
Download, untar and run. If you need further instructions, then you are not ready for this script (again, it is very unpolished, not for general use).
 
Download link: https://mega.nz/#!YvYUhayC!CI1fl52V4tV0G4oqUib4W-NlMpVSpLDp8kmo74g-V08
 
Things that you can try with this script, on a X session:
 
Use a 1080p@30fps h264 video, and play it with "mpv -hwdec <filename>". You'll see in the logs that it is decoding through v4l-m2mcopy Install and run glmark2-es2 Use Chromium WebGL Play a 1080p@30fps video in YouTube in full-screen smoothly. I'm pretty sure it is not really using HW decoding as it claims (there is no  initialization message in dmesg), but it's smooth for sure.  
Gstreamer is tested not to work, in some other forum I was told that Bionic version is not enough and I need to compile a newer one.
 
Performance is not in any way good, but it is a starting point. Anyway, the first TO-DO is getting the mali module integrated into the kernel, so there is no need to compile it separately.

I think that process is not necessary anymore, armbian-config should be enough to take care of configuring the locales.  @köksal please confirm if it worked for you.

Using mpv from the command line console should give you a log, with info about the decoder and display driver it is using. Also with gst-play-1.0 for gstreamer.
 
Also, running glmark2-es2 will tell you whether it is using Mesa SW emulation, or Mali.
 
For last, if you have configured chromium to use acceleration (like my script does), you can check whether it is working by typing in the address bar "chrome://gpu"
 
Edit: And, of course, you can also check /var/log/Xorg.0.log

Well, no fancy introduction here, because this doesn't pretend to be a script for the general use, only for testers who want to try the current *very early* status of the media capabilities in the Armbian meson mainline kernel.
 
Warning: It will replace your current kernel with a pre-compiled nightly 4.19.20.
 
Instructions:
Download, untar and run. If you need further instructions, then you are not ready for this script (again, it is very unpolished, not for general use).
 
Download link: https://mega.nz/#!YvYUhayC!CI1fl52V4tV0G4oqUib4W-NlMpVSpLDp8kmo74g-V08
 
Things that you can try with this script, on a X session:
 
Use a 1080p@30fps h264 video, and play it with "mpv -hwdec <filename>". You'll see in the logs that it is decoding through v4l-m2mcopy Install and run glmark2-es2 Use Chromium WebGL Play a 1080p@30fps video in YouTube in full-screen smoothly. I'm pretty sure it is not really using HW decoding as it claims (there is no  initialization message in dmesg), but it's smooth for sure.  
Gstreamer is tested not to work, in some other forum I was told that Bionic version is not enough and I need to compile a newer one.
 
Performance is not in any way good, but it is a starting point. Anyway, the first TO-DO is getting the mali module integrated into the kernel, so there is no need to compile it separately.

Welcome!
 
Avoid Banana M3 at all costs. Besides that, all three other devices are good, depending on your budget and how good of a deal you can get.
 
Probably Nanopi M4 is still a bit immature on the software side (too new), but if you plan to use it in the long term, it's a good choice.
 
XU4 is rather old, but it is still a great computer, and software support is excellent. Plus, now you can find it very cheap. I recommend buying in Ameridroid and adding a emmc module.
 
Tinkerboard S is a great machine, with very good software support too. Though, you'll need to find a very good microusb cable for powering, which is not always easy, and also this board will probably be the most expensive of the three.

Well, no fancy introduction here, because this doesn't pretend to be a script for the general use, only for testers who want to try the current *very early* status of the media capabilities in the Armbian meson mainline kernel.
 
Warning: It will replace your current kernel with a pre-compiled nightly 4.19.20.
 
Instructions:
Download, untar and run. If you need further instructions, then you are not ready for this script (again, it is very unpolished, not for general use).
 
Download link: https://mega.nz/#!YvYUhayC!CI1fl52V4tV0G4oqUib4W-NlMpVSpLDp8kmo74g-V08
 
Things that you can try with this script, on a X session:
 
Use a 1080p@30fps h264 video, and play it with "mpv -hwdec <filename>". You'll see in the logs that it is decoding through v4l-m2mcopy Install and run glmark2-es2 Use Chromium WebGL Play a 1080p@30fps video in YouTube in full-screen smoothly. I'm pretty sure it is not really using HW decoding as it claims (there is no  initialization message in dmesg), but it's smooth for sure.  
Gstreamer is tested not to work, in some other forum I was told that Bionic version is not enough and I need to compile a newer one.
 
Performance is not in any way good, but it is a starting point. Anyway, the first TO-DO is getting the mali module integrated into the kernel, so there is no need to compile it separately.

So, since RK started to create tags, I guess we can just use them and forget about the old problem of the default 4.4 kernel being a constant pain, right? It's also very comforting to see that they paid attention to our requests in that matter.

So the Media Script is finally released:
 

I see some structural challenges here.  One is a perceived hierarchy perhaps keeping some people from mentioning issues (to be honest we already have that problem, I've had small issues in images for months before someone pointed it out).  If we take this route, then the forum has to be as open as possible to general user complaints.  Restricting access results in a shrinking of community in general, it's a difficult position because in order to grow the community you have to allow "know-nothings" to ask questions and hopefully become "know-somethings".  We also need to find a good way to appeal to a more diverse user base, application wise. 
 
People like @Larry Bank and @sgjava have done some great work, but our willingness (and ability) to support ends with server-type environments (nothing wrong with this, but it is a *very* limited niche of people who can contribute to that specific task thing)
 
@JMCC is doing great work with media, if we can roll at least some of what he's doing into the build script it would be fantastic (I was thinking we should package his scripts as part of a board or family specific armbian-config menu)
 
So we have the groundwork for IoT and Multimedia applications, which will make our little Linux project more interesting for the general public, especially if we can make these things somewhat standard, we get more users.  from those users, some programmers/maintainers/mods/etc will show up.  The issue is the age old one of humanity:  Talent and interest are hard to find together. If the vendors are not willing to help, despite the value, then we need to move an insane number of people through the forums to snag ones that are able and willing to contribute.
 
I think we do need to approach the "slimming down" of our boards a bit more carefully.  This is something along the lines of @tkaiser's comments about this being a project for us, with our help to everyone else being a happy side-effect.  If we are not overwhelmed, we make better things, the community benefits.  If a high-level user wants their board supported badly enough, they will work to support it (Me with Tinker Board)  We need to add a "maintainers" list or something similar, this is for one simple reason:  boards with no maintainer need to be put on probation.  A stronger definition of individual roles (not in a leadership sense, just in a contribution sense) will help as well I think. 
If a board has no maintainers and no vendor support, it should be "CSC'd", with a list on the website with "looking for maintainers"  I would propose we not make images for those boards available on the download page, allow people to build them if they want.  That alone filters who would be asking questions.
 
So, for boards:
 
Each board entry should include 2 additional fields:
Maintained-by  (Member or members) Vendor-supported (Does the Vendor give Armbian anything more than just a couple boards?  I include technical support here) So Tinker Board and Le Potato would look like:
supported-by: tonymac32 vendor-supported: yes  (or we could make tiers, everything from boards on demand, technical support, direct code contribution, money)  
For Member-contrubtors:
 
boards hosting documentation etc So Igor (sorry if I massively under-represent:
 
Build Script Author (obviously multiple people can have each tag) Web Admin Build Hosting Family-Allwinner Family-Freescale Documenter etc I can expand on this later in a specific thread since it covers a wide topic matter.

Pssssst:
 

 
So, this has @Myy's work with the patchset that got dropped on the mailing list for vdec, I've gotten everything building properly (minus a wireless driver and we don't have 1.7 and 1.8 GHz opps)
 
I ran the media script ans installed everything.
 
I'm watching a 1080p mp4 at fullscreen, here is my armbianmonitor -m:
 
Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 05:41:25: 1608MHz 1.00 20% 3% 16% 0% 0% 0% 51.7°C 0/11 05:41:30: 1608MHz 0.92 20% 3% 17% 0% 0% 0% 50.4°C 0/11 05:41:35: 1608MHz 0.92 21% 3% 17% 0% 0% 0% 50.4°C 0/11 05:41:40: 1608MHz 0.93 19% 3% 15% 0% 0% 0% 51.2°C 0/11 05:41:45: 1608MHz 0.93 20% 3% 17% 0% 0% 0% 50.4°C 0/11 05:41:50: 1608MHz 0.94 21% 5% 16% 0% 0% 0% 51.7°C 0/11 http://ix.io/1zbd
 
As for functionality, gstreamer does not seem to want to work, so I would guess the vdec isn't operational yet, or something isn't quite right.  In any case, there is hope, perhaps.  ;-)

Be sure that ROCKCHIP_MPP is enabled in the kernel configuration. It's not automatically set up.
The driver is available in "Device Drivers -> Staging drivers -> Rockcihp MPP".

Generally you get some warning, like for the Realtek staging driver, telling you that the code isn't that great, etc...

Hello.
 
Linux rockpro64 4.4.167-rockchip64 #12 SMP Wed Jan 23 00:26:14 CET 2019 aarch64 aarch64 aarch64 GNU/Linux
media script installed. System was switched to nigthly.
 
ls -l /dev/mali*
ls: cannot access '/dev/mali*': No such file or directory

Good to see that you like experimenting. As I said, if you use as a base anything other than Armbian Bionic Default image, results can be unpredictable. I invite you to use the build script to make a proper image, or wait until it is publicly released, if you want to take advantage of all the possibilities of the script.

Yes, actually "Desktop acceleration" means here "Desktop GPU integration". Ironically, when using the X server, that very often means that the Desktop will be slower and laggier when "accelerated". It even happens on my desktop Intel Core i7 computer . It's a fault of the terribly outdated X protocol; just imagine all Windows 10 graphic stack was running on top of the Windows 3.1 graphic system: that's something similar to what we are doing today in Linux.
 
That is precisely the reason why Wayland appeared. Now it is getting more mature, and is without any doubt the future for Linux desktop in general. And even more in embedded systems, which don't support the full OpenGL API, but only a reduced version (OpenGL for Embedded Systems), designed basically to run Android and similar OSes. On the other hand, Wayland is much more similar to the Android graphics API, which is what those SoC's are designed for.
 
So, in short: X server sucks, even more when it comes down to acceleration, and even more when you want to perform that acceleration with a device that only supports OpenGL-ES (i.e. a Mali GPU). Right now, I'm working on Amlogic X acceleration, and I'm getting more and more convinced that we need to move to Wayland if we want to get serious about accelerated desktop.

As promised we prepare a little patch for our RockPi... Since it's a while since we created our branch it makes sense to sync our branch with upstream. with:
git fetch upstream && git merge upstream/master && git push (followed by your username & password to keep the branch updated)
 
 
 
It's not allays that much.. but it's worth to do it before you start with development. according to radxas device tree the RockPI has two configurable LEDs.
https://github.com/radxa/kernel/blob/c26d93d001494bbeec86d62e9954b932f254776c/arch/arm64/boot/dts/rockchip/rockpi-4b-linux.dts#L271-L284
gpio-leds { compatible = "gpio-leds"; user-led1 { gpios=<&gpio3 28 GPIO_ACTIVE_HIGH>; linux,default-trigger="heartbeat"; default-state = "on"; }; user-led2 { gpios=<&gpio3 29 GPIO_ACTIVE_HIGH>; linux,default-trigger="heartbeat"; default-state = "on"; }; If we don't know what we can do with those we can look into documentation:
https://www.kernel.org/doc/Documentation/devicetree/bindings/leds/leds-gpio.txt
and from there:
https://www.kernel.org/doc/Documentation/devicetree/bindings/leds/common.txt
 
you see we've quite some options to set our LEDs. At the moment there's different usage in Armbian but I prefer to have one LED always on, ant the other one in heartbeat (some indication in case the board crashes). We could also set one LED to disk-activity but as an example this should do the job. A bit a more useful name for the nodes could also help who knows which led is which if they're named led1 and led2...
so first make sure we're on the right branch and have create patch properly set nano default-config.conf: (cause we build dev image set EXPERT="yes")
CREATE_PATCHES="yes" # wait that you make changes to uboot a$ BUILD_ALL="no" # cycle through available boards and ma$ # set KERNEL_ONLY to "yes" or "no" to b$ BSPFREEZE="" # freeze armbian packages (u-boot, kern$ INSTALL_HEADERS="" # install kernel headers package LIB_TAG="rockpi_tutorial" # change to "branchname" to use$ CARD_DEVICE="/dev/mmcblk0" # device name /dev/sdx $ EXPERT="yes"  
if we now compile for our board we will be prompted to make changes once for ATF (we don't, our little change has nothing to do with ATF) u-boot (we could.. but heartbeat doesn't make sense here.. we want it once the board is booted fully up) and kernel.
ATF:
[ warn ] Make your changes in this directory: [ /home/chwe/armbian/build/cache/sources/arm-trusted-firmware-rockchip64/rockchip ] [ warn ] Press <Enter> after you are done [ waiting ] [ warn ] No changes found, skipping patch creation u-boot:
[ warn ] Make your changes in this directory: [ /home/chwe/armbian/build/cache/sources/u-boot-rockchip64/rockchip-master ] [ warn ] Press <Enter> after you are done [ waiting ] okay.. it might make sense to fix the RockPi DT in u-boot as well... That's how the DT looks at the moment (armbian/build/cache/sources/u-boot-rockchip64/rockchip-master/arch/arm/dts/rk3399-rockpi4b.dts):
as you can see.. wrong gpios and a naming which is IMO also not satisfying... Let's change it to:
as you can see, we didn't use heartbeat yet (and the gpios are also wrong).. and now for the kernel:
[ warn ] Make your changes in this directory: [ /home/chwe/armbian/build/cache/sources/u-boot-rockchip64/rockchip-master ] [ warn ] Press <Enter> after you are done [ waiting ] /home/chwe/armbian/build/cache/sources/linux-rockchip64/4.20.0-1083-ayufan/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts
keep in mind.. we've to change it in the LED node and the pinctrl node..
 
in build/output/patch we get two patches:
u-boot-rockchip64-dev.patch:
and for the kernel: (kernel-rockchip64-dev.patch)
now let's boot the image.. The green led is bright as hell.. and the red one shows heartbeat..  annoying.. let's change them vice versa and hope that everything was right..
as long as we keep the patches in output without renaming them, they get applied in the next run we build an image.. and the can "edit" them. so it's just change gpios in the DT..
hmm seems that now both LEDs are always on.. so something is wrong here.. either the DT from the BSP kernel isn't correct.. or it doesn't work..
means, we've no idea how to trigger the green LED. But we know how to trigger the RED LED. Now let's write a patch which only triggers the RED LED and erase the other LED node cause we've no clue how to trigger it.
U-boot:
diff --git a/arch/arm/dts/rk3399-rockpi4b.dts b/arch/arm/dts/rk3399-rockpi4b.dts index 5d73ce5..5574e9b 100644 --- a/arch/arm/dts/rk3399-rockpi4b.dts +++ b/arch/arm/dts/rk3399-rockpi4b.dts @@ -65,14 +65,9 @@ status = "okay"; compatible = "gpio-leds"; - power-led { - label = "power"; - gpios = <&gpio0 11 GPIO_ACTIVE_HIGH>; - }; - - standby-led { - label = "standby"; - gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>; + system-status { + label = "status"; + gpios = <&gpio3 28 GPIO_ACTIVE_HIGH>; }; }; Kernel:
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts b/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts index 7f10da2a8..1d4721dcc 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts +++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts @@ -140,20 +140,15 @@ }; leds { + status = "okay"; compatible = "gpio-leds"; pinctrl-names = "default"; - pinctrl-0 = <&work_led_gpio>, <&diy_led_gpio>; - - work-led { - label = "work"; - default-state = "on"; - gpios = <&gpio0 RK_PB3 GPIO_ACTIVE_HIGH>; - }; + pinctrl-0 = <&status_led_gpio>; - diy-led { - label = "diy"; - default-state = "off"; - gpios = <&gpio0 RK_PA2 GPIO_ACTIVE_HIGH>; + system-status { + label = "status"; + gpios = <&gpio3 29 GPIO_ACTIVE_HIGH>; + linux,default-trigger = "heartbeat"; }; }; @@ -643,12 +638,8 @@ }; leds { - work_led_gpio: work_led-gpio { - rockchip,pins = <0 RK_PB3 RK_FUNC_GPIO &pcfg_pull_none>; - }; - - diy_led_gpio: diy_led-gpio { - rockchip,pins = <0 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>; + status_led_gpio: status_led_gpio { + rockchip,pins = <3 28 RK_FUNC_GPIO &pcfg_pull_none>; }; }; Now since we know that our patch works, let's give it a meaningful name and move it in the correct folder. the patchname makes it easy for you.. and rename it to a meaningful name. (build/patch/kernel/rockchip64-dev & build/patch/u-boot/u-boot-rockchip64-dev). For the beginnings fix-rockpi4b-led.patch sounds ok-ish. We've to check if those new patches apply correctly after moving to the right folder:
uboot:
[ o.k. ] * [l][c] add-board-renegade.patch [ o.k. ] * [l][c] add-board-rockpi4b.patch [ o.k. ] * [l][c] add-missing-SDMMC0_PWR_H-rockpro64.patch [ o.k. ] * [l][c] add-u-boot-delay-rockpro64.patch [ o.k. ] * [l][c] board-renegade-updates.patch [ o.k. ] * [l][c] enable-DT-overlays-support.patch [ o.k. ] * [l][c] fix-rockpi4b-led.patch and kernel:
[ o.k. ] * [l][c] RK3328-enable-1512mhz-opp.patch [ o.k. ] * [l][c] RK3399-enable_1.5_2.0_ghz_cpufreq_opp.patch [ o.k. ] * [l][c] add-board-rockpi4b.patch [ o.k. ] * [l][c] add-fusb30x-driver.patch [ o.k. ] * [l][c] board-rockpi4-dts-wip-fixup.patch [ o.k. ] * [l][c] firefly-rk3399-enable-wifi.patch [ o.k. ] * [l][c] fix-rockpi4b-led.patch [ o.k. ] * [l][c] fix-rockpro64-emmc.patch [ o.k. ] * [l][c] fix-spi1-flash-speed.patch [ o.k. ] * [l][c] general-add-overlay-compilation-support.patch [ o.k. ] * [l][c] general-increasing_DMA_block_memory_allocation_to_2048.patch [ o.k. ] * [l][c] general-packaging-4.17-dev.patch [ o.k. ] * [l][c] general-rockchip-overlays.patch [ o.k. ] * [l][c] nanopi4-dts.patch [ o.k. ] * [l][c] orangepi-rk3399-dts.patch [ o.k. ] * [l][c] renegade-add-HDMI-nodes.patch [ o.k. ] * [l][c] renegade-enable-usb3.patch [ o.k. ] * [l][c] rk3328-sd-drive-level-8ma.patch [ o.k. ] * [l][c] rk3399-sd-drive-level-8ma.patch [ o.k. ] * [l][c] timekeeping32-tweaks-for-4.20.y.patch [ o.k. ] * [l][c] unlock-temperature.patch seems that everything is okay. So it's time to bring them back to armbian. Let's check our repo with git status:
chwe@chwe-HP:~/armbian/build$ git status On branch rockpi_tutorial Your branch is up to date with 'origin/rockpi_tutorial'. Untracked files: (use "git add <file>..." to include in what will be committed) patch/kernel/rockchip64-dev/fix-rockpi4b-led.patch patch/u-boot/u-boot-rockchip64-dev/fix-rockpi4b-led.patch nothing added to commit but untracked files present (use "git add" to track) there are our two new patches.. lets add and commit (with a meaningful commit message) them with: git add -A && git commit followed by git push
chwe@chwe-HP:~/armbian/build$ git push Username for 'https://github.com': chwe17 Password for 'https://chwe17@github.com': Counting objects: 9, done. Delta compression using up to 8 threads. Compressing objects: 100% (9/9), done. Writing objects: 100% (9/9), 1.50 KiB | 1.50 MiB/s, done. Total 9 (delta 5), reused 0 (delta 0) remote: Resolving deltas: 100% (5/5), completed with 4 local objects. To https://github.com/chwe17/build.git a156fddf..bb63ed6d rockpi_tutorial -> rockpi_tutorial https://github.com/chwe17/build/tree/rockpi_tutorial
our features branch is now one commit ahead of armbian master and we can create a PR against armbians master:
https://github.com/armbian/build/pull/1236
 
You see, just adding something simple like triggering an LED to heartbeat can give you some headache.. and takes more time that we expected cause the second LED didn't behave as we thought. But finally, we got it.
 
Edit: this post was written 'on the fly'.. If something isn't clear, just let me know.. and I'll try to explain it better.
Edit2: cause 'we know' that @TonyMac32 does a lot with RK boards we request him as reviewer.

So the Media Script is finally released:
 

Aha, I got it. We were missing the firmware.
 
Here is the output of mpv. Notice the line confirming the use of hardware decoding:
 
Here is a ffmpeg output:
 
Though, performance is far from being good yet. Let's see if I can find some time to package everything I have so far into a script, for others to test too.
 
I'm attaching the firmware here. @Igor I'm going to add it to the armbian/firmware repo.
meson-firmware.tgz

Hello. I'm still testing, I want to post a howto/script when I have some more results.

Depends on your board. If it's armhf, you can use Raspbian Stretch repos, otherwise you may need to build. I recommend to build from source in any case, I did it once and didn't take long.
 
https://wiki.x2go.org/doku.php/wiki:repositories:raspbian

Hello. I'm still testing, I want to post a howto/script when I have some more results.

These are the areas that need more testing:
Using MPV and Gstreamer video players, and reporting performance. We need to choose which of the two will be the default player in the Armbian multimedia implementation. Performance of Chromium streaming, playing unencrypted videos (e.g. Youtube) at different resolutions, and also DRM encrypted videos (Netflix, Amazon Prime Video, etc.). General desktop experience, when using regular desktop apps (text editors, pdf readers, libreoffice, etc). Thx. 

https://github.com/armbian/documentation/commit/63c02d26ceca64d032696247e7c4657f4656a1ce
https://github.com/armbian/build/commit/730c1f6f4d6a5f45418c39e789f63b8da4fb1411 (not yet included in latest images, but included via apt update)

1m from router.

RTL8188CUS
RTL8188EUS
MT7610 at 5G
MT7601U