midix

Thanks for the helpful hints. For now, I managed to create something hacky using the following approach: In debootstrap-ng.sh I commented out the line # rm -rf $SDCARD So now I had left valid rootfs and I could do armccrootpath=/home/vagrant/armbian/.tmp/rootfs-next-nanopineo2-bionic-no mount -t proc chproc $armccrootpath/proc mount -t sysfs chsys $armccrootpath/sys mount -t devtmpfs chdev $armccrootpath/dev || mount --bind /dev $armccrootpath/dev mount -t devpts chpts $armccrootpath/dev/pts cp /usr/bin/qemu-aarch64-static $armccrootpath/usr/bin/ chroot $armccrootpath From there, I continued as usual and was able to compile ZynAddSubFx. I tried to create a deb using checkinstall tool, but unfortunately it failed during tar process and complained about many missing Voice files. So I gave up, zipped entire zynaddsubfx folder with build results and just copied it over to nanopineo2 and ran `make install` there. It worked just fine at the end.

I don't want to torture my SD card with full OS image rewrites or compilation on the device itself, so I would like to cross-compile. I just set up a ubuntu/bionic64 VirtualBox through Vagrant using https://github.com/armbian/build Currently, I don't want to build entire image or kernel from scratch but I noticed that compile.sh and related scripts contain many convenience functions and tools. I already started compile.sh once to let it prepare the virtual machine for cross-compile tasks and it successfully installed all the dependencies. I got especially interested in extras-buildpkgs folder. As I understand, I can put my own package descriptions there and Armbian tools will find it and offer to create packages for it? Is there any simple way to leverage Armbian tools to create a deb package of a single third party program (ZynAddSubFx, to be more exact - I already have it compiled once directly on an ARM device, so I know it's doable) without compiling the kernel or OS? Ideally, I would like to get the "make install" results of the software to be collected into a deb package, so I can just install it on the target machine (NanoPi Neo2, to be specific).

Thank you, after configuring it works fine and in stereo! So, I guess the audio codec drivers supplied by FriendlyElec were messed up. The sound quality is OK - good enough for listening on headphones or any non-hifi system. Will see how it works with ZynAddSubFx soon.

Armbian_5.59_Nanopineo2_Ubuntu_bionic_next_4.14.65.img does not see the sound codec at all. The status matrix here: http://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix tells that Audio Codec should be supported since kernel 4.12 on H3 (H2+ is the same, as far as I know). But Armbian does not see the audio codec nor on NanoPi Neo2 (H5), nor even on on NanoPi Duo (H2+), although all the img files I used have 4.14 in their name. However, even with FriendlyElec's own image nanopi-neo2_ubuntu-oled_4.14.52_20180628.img there is a different issue - the sound is mono instead of stereo! I tried speaker-test: speaker-test -Dsysdefault:Codec -c 2 -t wav speaker-test 1.1.0 Playback device is sysdefault:Codec Stream parameters are 48000Hz, S16_LE, 2 channels The test plays back the voice that says: Front Right / Front Left but the sound comes form both channels simultaneously. Tried also other devices reported by aplay -L: hw, hwplug. The same result - the sound is monophonic. I tested for short circuit by attaching another audio player right in parallel to my wires - the sound is stereo from the player, so there is no short circuit. Also, if I run the same test on a cheap external USB sound adapter connected to the NanoPi, it works correctly and plays stereo. I also tried the same speaker test on a NanoPi Duo with its Mini shield and connected headphones to 3.5 jack. The same result - no stereo sound even on the official 3.5 minijack. Has FriendlyElec missed the fact that their boards do not have stereo sound? Or is everyone using external USB soundcards (which seems redundant considering the in-built audio) or I2S? At the same time, my old CHIP with R8 (which essentially is A13) passes the same speaker-test without any issues - the sound is stereo. I posted a question on FriendlyElec forums about the issue, but at the end, I would like to use Armbian anyway. So, what are my options to get stereo sound out of H5 (and H2+) in-built audio codec using Armbian?

I live in a small Eastern European country and shipping from China still is almost always cheaper than from Germany or UK (and local stores are out of question when trying to find anything more exotic that RPi). I guess that's why FriendlyElec website also warns that EU orders are being shipped from China. Still curious about those AliExpress options, but I guess I'll better stay clear and order directly from FriendlyElec unless someone can confirm that there are trustworthy AliExpress stores that sell real NanoPis and not low quality clones (of course, SoC and layout being the same but peripherals might differ). Yep, I definitely can find a pressure sensor with SPI or I2C interface (built-in or a small board with analog pressure sensor). For my current ZynAddSubFx experiments I was using this tutorial: https://lucidbeaming.com/blog/setting-up-a-raspberry-pi-3-to-run-zynaddsubfx-in-a-headless-configuration/ slightly adjusting it to match CHIP and without the web part, just ZynAddSubFx without GUI. The author of the tutorial says that he could achieve under 10ms latency on RPi3: https://linuxmusicians.com/viewtopic.php?p=83076&sid=45be693c0e9857cffc43cb95cbaae206#p83076 No wonder - RPi 3 is much more powerful than my CHIP with its R8. But this makes me wonder if H2 / H3 also might be too weak for the purpose or if I'm doing something terribly wrong. Just for a very rough idea of CHIPs performance I added 7zip benchmark: No surprise here, considering that R8 (A13) is similar to A10, which is used in Olimex Lime A10, which has the lowest score in almost all the benchmarks: https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md So, maybe any SBC might be better than that for zynaddsubfx I'm launching Zyn with command: `zynaddsubfx -U -A=0 -o 128 -r 44100 -b 8192 -I alsa -O alsa -P 7777 -L "/usr/local/share/zynaddsubfx/banks/Choir and Voice/0034-Slow Morph_Choir.xiz"` Thus sample rate is 44100, buffer is 8192 (182ms latency, confirmed by Zyn in its output log). `top` shows that Zyn is using about 30% CPU when idle and jumps to 99% when I press MIDI keys on my Arturia MiniLab mkII. Zyn often spams with "underrun occurred" messages. I tried different buffer sizes, and found that 4086 => 92ms works better but still unable to handle fast subsequent notes; anything more or less than 4086 gives even worse results. Also tried to uninstall the manually compiled Zyn and install one from apt-get, but that fails on CHIP with errors like `snd_seq_event_input: Assertion `seq' failed.` and `snd_pcm_open failed` So, obviously Zyn version in the repository is not optimized or not supporting R8 or CHIPs OS (Linux chip 4.4.13-ntc-mlc #1 SMP Tue Dec 6 21:38:00 UTC 2016 armv7l GNU/Linux) and my custom build might be the best option.

Thanks a lot, I somehow missed NanoPi series entirely, shame on me. Those boards seem to be much better documented than Orange Pi products. I see NanoPis being sold also from Chinese companies RealQVol, Million Sunshine Technology and others, and not quite sure if they are just distributors or clones. I'm in Europe, so buying directly from FriendlyElec would ship from China, anyway; but other Aliexpress vendors offer better shipping rates (free), and also I can buy other interesting items from them, which are not available on FriendlyElec store. I just don't want to get caught by some low quality NanoPi "copycat" (in which case the quality and software and GPIO compatibility might be unknown). Yes, the topic where I found ZynAddSubFx mentioned had lots of useful info from @Da Alchemist

I've been considering some options for experiments with electronic wind instruments and synthesizers, such as ZynAddSubFx, Fluidsynth. I've seen project Zynthian and they are running it on a Raspberry Pi 3, so that should be a safe choice, right? Although I'm not sure if they are using some mainstream Debian or something heavily adjusted. Also, for a wind instrument I hoped to find something smaller so I can even build it into the instrument itself; although I don't have my hopes high on that - I'm not sure if I'll find an SBC with enough power. I happen to be one of lucky (or not) backers of NextThingCo C.H.I.P. (now mostly out-of-business company) and I have two CHIPs. So, I just tried one with ZynAddSubFx. Well, it jitters like hell, even with 20ms latency, while some RPi3 user claimed to have achieved around 5ms latency with the same setup (compiled from source, using ALSA and not jack). So, clearly CHIP with its R8 (essentially AllWinner A13) is not enough for playing ZynAddSubFx in real time. It seems, for most of Linux audio synths single core performance matters most because I'm not sure if they are optimized to leverage ARM benefits (at least not yet, but maybe they will in the future). Also, 32/64 bits might be not important at all. BUT - in some benchmarks I've seen that Cortex-A53 running at the same clockspeed as A7 shows almost ~30% better performance even for 32 bit programs? So, it might be worth choosing H5 over H3 in any case? Memory usage - not so important; I don't want to load entire soundbank of samples into RAM. So, 512MB might suffice, although 1GB seems more future-proof. Not sure yet. And, of course, I don't care about video decoding (unless it's possible for some software synth to use video chip as an additional CPU, but it seems highly unlikely) and network performance Looking through these forums, I found one person claimed to be using ZynAddSubFx on a Orange Pi (presumably H3?) and being satisfied with the results. Does this mean that 4 x Cortex-A7 CPU-cores of H3 work better than 1 x Cortex-A8 CPU-core of R8? Yes, there are 4 cores, but is the OS distributing the load evenly across all of them thus making sound synthesis more efficient? Does leveraging of multiple cores depend more on the OS (Armbian specifically) or on ZynAddSubFx ? Again not sure. I only know that for now I should stay away from H6 because it's not yet completely supported and I'm not sure if it would give any benefits for my case, unless it could provide more horsepower for the synths even at this early stages of Linux support? I don't need super high audio quality, but seeing that those smaller boards don't have audio out, it seems I'll need an I2S output and an addon board anyway (and Orange Pi sells even sets of SBC + I2S board, so that might be a nice option). Unfortunately, analog IO pins are a rarity and I'll have to add an Arduino anyway to deal with all the sensors (touch buttons and breath sensor), but then having reliable SPI or I2C is mandatory for me! This might exclude many options. Which boards have reliable SPI or I2C support in Armbian? So, CPU wise, my choices (besides obvious RPi3B+) seem to be H2+/H3 (seems to be the same thing) or H5 (if there is any reason to go for 64 bit in my specific case) or RK3328. And finally the price. The cheapest Rpi 3 B+ I can get is 45 USD (with shipping). In comparison, ROCK64 with 1GB RAM is 36 USD (with shipping). But they are too large to consider building into an EWI, so I would have to run wires (which I might have to do anyway, if my idea to build everything into the EWI itself fails for some reason). Only Orange Pi offers small form factor in their Zero models (H2+, H3, H5 based). What do you think? Is it worth trying to find a small factor SBC for ZynAddSubFx among those Orange Pis or should I go for ROCK64?