Odroid xu4 / linux tweaks.

I know that the time has gone... but it works very well with armbian on a ODROID XU4Q, adding the 3 lines to the limits.conf file, as explained in "README_LINUX.TXT".
To avoid the single note or single chord delayed, try giving a higher minimum frequency, in armbian it is done by editing the file /etc/defaults/cpufrequtils.
I set the desktop enviroment to auto login (I think at first boot), and added Pianoteq as an auto-start app (settings -> session and startup -> application autostart)
By the way, I removed all the other apps from autostart.
I use a UDJ6 audio interface, which is not the best in the market, but it works. I set the sound card to 48 kHz and internal sample rate to 32 kHz, with a buffer size of 96 samples. Polyphony set to 96. (Let's face it, no one of us can hear anything above 16 KHz).
The selected device is "UDJ6 direct hardware without any conversion". The output is set to "stereo" (the sound card has six independent output, in stereo mode, it clones 1,2 to 3,4 and 5,6)
The command added to the autostart settings is:
nice -10 taskset 0xF0 ./home/marcos/Pianoteq --headless
I see you know what is nice about, taskset tells where the program is run. XU4 has 4 little cores (0-3) and big ones (4-7), I did some benchmarking and even though performance can be better using the eight cores, is more consistent using just big ones (0xF0 hex = 11110000 bin, where each 1 or 0 represents a core).
With this config, I get a very good performance, no notes are lost and the latency is about 18ms (measured with an oscilloscope, trigger on midi signal, and the sound in another channel). Another better configuration I haven't tested yet in real life is 44.1 kHz / 64 samples / 96 polyphony, which gives a latency of 13 ms.
I boot from a Sandisk Extreme 32Gb, and can start playing 24s after connecting power.

PS:
If you or someone is interested I can translate and upload my benchmark program (very rough since I'm not a programmer). What the program does is generate a midi file with ten gilssandi over the 52 white keys, faster and faster, until Pianoteq fails. No note is released until the the ten glissandi are finished (except for the polyphony limitation).
My benchmark results are, three repetitions, the worst result of three tests:
44.1 kHz / 64 samples / 96 polyphony: 24.2 ms between notes, then there are fails. Latency: 13.2 ms (average of 5 measurements with the osc.)
44.1 kHz / 128 samples / 96 polyphony: 19.1 ms between notes, latency: 21.9 ms
48 kHz / 64 samples / 96 polyphony: 39.3 ms between notes, latency: 12.1 ms
48 kHz / 128 samples / 96 polyphony: 41.21 ms between notes, latency: 20.3 ms
32 kHz / 96 samples / 96 polyphony: 6.74 ms between notes (insane!), latency: 17.9 ms
Results are not 100% accurate because of throttling that occurs when the processor hits 80ºC, it goes down from 2GHz to 1.8, and then 1.6, and sometimes 1.5 GHz.
I would like to re compile the kernel and leave just the necessary parts of it, and use a lower runlevel... but I think I will use this config for a while.
I plan to make a MIDI panel with a couple of buttons and knobs or faders to select the instruments and use the volume of Pianoteq, now it only plays the Steinway D in its default preset.