Hi, I’d like to share some key points about this new platform. Yes, it really is a completely new platform.
This information was extracted from the system registry, a very long 3.44 MB file! (Technical data from systemlog! - #28 by irro94)
Then, because I’m lazy, I fed it to ChatGpt, and this is the result.
So, basically, a new ARM SOC, A-57 + M7.
Is 8 GB the amount of RAM, or does it mean NAND used as the working/scratch directory?
Let’s work together to learn more about our new TV!
Key Facts (summary)
Linux Kernel: 6.12.34, PREEMPT_RT build, compiled with GCC 13.2.0 (Mon Jun 30 2025);
SoC / CPU: NXP i.MX8MP (rev 1.1), ARM64 platform, 4 CPUs enabled; detected CPU features like CRC32, VIPT I-cache;
Memory: ~8 GiB total (8,388,608 KB) with CMA reserved ≈ 960 MiB;
Storage:
SDXC card mmcblk1 (label: SD64G — ~58.3 GiB)
eMMC mmcblk2 (DG4008 — ~7.28 GiB) with multiple partitions (p1–p4).
Filesystems in use: exFAT, FAT, ext4, squashfs.
Boot / updates: A/B partition scheme (rootA/rootB). Current boot is rootB. Kernel cmdline shows bootpartition=boot0, activeroot=rootB, conf=esp5, board_rev=v3.1. Logs show first boot after update.
Init / userspace:systemd 255.4 in use. Application stack includes esp5-engine (mb-engine), ui-client, audio stack (pipewire, wireplumber, pw-jack), update system swupdate (v2024.12.1). Custom scripts mb-* (fuses, license-check, update-check, system-setup).
Kernel cmdline:activeroot=rootB bootpartition=boot0 board_rev=v3.1 conf=esp5 rcutree.kthread_prio=95. Defines which root is active and selects config esp5;
Mount points in logs:/apps, /data, /var/volatile, /shared, /srv, /data/log/coredump, /mnt/sdcard. Overlay mounts for /apps cleaned at shutdown. Some partitions busy/unmountable at shutdown (/data).
Networking / Bluetooth: warnings show org.bluez and net.connman services not running — likely not included/enabled;
Runtime Notes / Errors
Engine failures: repeated "failed to connect to the engine" (UI-client can’t reach IPC socket).
Does anyone have any insights on how the multisampler handles memory?
I’m trying to generate multisamples outside the tonverk and so far i’ve managed to generate patches that reads up to 32 velocity layers, and then crashes.
In this case I’ve used arbitrary trim-start and trim-end points, and looking more deeply into the .elmulti files that the TV generates, i noticed that every trim point is placed at a multiple of 512
The multisample recorder allows recording for 128 velocity layers across 128 keys which amounts to a whopping 16384 slices (in theory)
To handle this amount of data and to quickly jump from a point to another, I’m assuming there must be some buffer allocation going on (which might explain the crashes due to buffer misalignment or something), but I’m quite new to all this so I’m wondering if I’m not missing something obvious
I’ve tried adding padding so that each slice’s sample length is a multiple of 512, 1024 or 2048, but in every case it crashes at layer 32
Do you mean the audio file size? I’m using pretty short drum loops and it doesn’t seem to make a difference whether they are split in separate files or aggregated into a single file.
Here is a typical audio sample I use, roughly 1MB
Channels : 2
Sample Rate : 44100 // I handle the conversion to 48000 on export
Precision : 16-bit
Duration : 00:00:02.43 = 107328 samples = 182.531 CDDA sectors
File Size : 429k
Bit Rate : 1.41M
Sample Encoding: 16-bit Signed Integer PCM
When i concatenate 127 audio files the resulting audio file is around 100MB
Ah ok. The obvious first thing would have been you were running out of memory.
You said you’re generating the multi samples outside of tv? I wonder if as a control we could test a tv generated multi sample of similar complexity to eliminate that as a source of error.
Yes ! A Tonverk *.el* file validator would be a godsend
I’ve generated a 128x128 multisample file with super short silent samples (50ms or so) and although the .elmulti file I generate seems to match its structure, my TV crashes 128x128.emulti (3.0 MB)
