Sorry for throughing ideas and plans around… and I have no time to test by myself. This article was written by Jeremy - a specialist for audio on Linux (Raspi):
https://autostatic.com/2017/06/27/rpi-3-and-the-real-time-kernel/
Perhaps this is also something for Zynthian. I made some tests with RT-Kernels - but everything I got was a freeze after some seconds… I will tests this the next weeks - if others will not be faster 
Regards, Holger
Ok - I could not resist:
wget http://www.parasitstudio.de/zynthian/linux-firmware-image-4.9.47-rt37-v7+_4.9.47-rt37-v7+-1_armhf.deb
wget http://www.parasitstudio.de/zynthian/linux-headers-4.9.47-rt37-v7+_4.9.47-rt37-v7+-1_armhf.deb
wget http://www.parasitstudio.de/zynthian/linux-image-4.9.47-rt37-v7+_4.9.47-rt37-v7+-1_armhf.deb
wget http://www.parasitstudio.de/zynthian/linux-libc-dev_4.9.47-rt37-v7+-1_armhf.deb
dpkg -i *.deb
Comment out the original line of your kernel and add the following line:
kernel=vmlinuz-4.9.47-rt37-v7+
Until now it works… really nice!
# uname -a
Linux zynthian-stage 4.9.47-rt37-v7+ #1 SMP PREEMPT RT Thu Sep 7 10:52:19 CEST 2017 armv7l GNU/Linux
USE AT YOUR OWN RISK!
Thanks to Jeremy (autostatic)!
Can i try 
? Being fresh of restoring… It’s the right moment… What if i want to rollback?
Whoa? Rollback? Why???
Make a copy of a working image (Linux: dd, Windows: ?) before installing.
Regards, Holger
… and here is some information on how to change schedulars and priorities per PID: http://taste.tuxfamily.org/wiki/index.php?title=Tricks_and_tools_for_PREEMPT-RT_kernel
With CustomPiOS I managed to make a realtimepi distro that takes a zynthian distro, and adds a realtime kernel to it. You can download the result (That still needs works, like updating the hostname), here: http://unofficialpi.org/Distros/ZynthianOS/nightly/realtime/
If we could optimize stuff like the priorities it could be an out-out-the-box realtime audio processor.
After playing with the violin - defiantly getting delay. I want to make a setup where I can test latency. Does anyone know of anything more fancy than plugging mice to speaker, adjusting the POTS on an audioinjector, and running jack_iodelay?
Saw that, but I don’t need that wiring when the audio injector has potentiometers to change the volume and input.
Ok, did testing. With an audio injector and the current jack2 settings I get 64.957ms latency, which is not so great. Any recommendations what to change?:
Some photos of the setup.
2. Started over ssh jack_iodelay.
I created a mod-ui layer. and added a pedal for gain and just reverb because I wanted to see if it effected latency (it didn’t). Also a CEO for testing. Looks like this:
I ran over ssh DISPLAY=:0 qjackctl. Due to some weird behavior of the gui to get the window to display I had to run this after a few seconds (it just lists existing windows, I wasn’t sure where the window was, and that made it pop up):
DISPLAY=:0 xwininfo -tree -root
Then wire up the audio injector to itself:
Then wiring in jack, basically wire the first effect to jack_delay, and the last pedal to system out. Then wirte capture to jack_delay:
Then look at the runnign jack_iodelay. Output is:
3117.947 frames 64.957 ms total roundtrip latency
extra loopback latency: 45 frames
use 22 for the backend arguments -I and -O ??
3117.947 frames 64.957 ms total roundtrip latency
extra loopback latency: 45 frames
use 22 for the backend arguments -I and -O ?? Inv
3117.947 frames 64.957 ms total roundtrip latency
extra loopback latency: 45 frames
use 22 for the backend arguments -I and -O ??
3117.947 frames 64.957 ms total roundtrip latency
extra loopback latency: 45 frames
use 22 for the backend arguments -I and -O ?? Inv
3117.947 frames 64.957 ms total roundtrip latency
extra loopback latency: 45 frames
use 22 for the backend arguments -I and -O ??
3117.947 frames 64.957 ms total roundtrip latency
extra loopback latency: 45 frames
use 22 for the backend arguments -I and -O ?? Inv
Ok, so I changed in /etc/systemd/system/jack2.service
ExecStart=/usr/bin/jackd -P 70 -t 2000 -s -d alsa -d hw:0 -r 44100 -p 256 -n 2 -X raw
to:
ExecStart=/usr/bin/jackd -P 70 -dalsa -dhw:0 -r48000 -p128 -n2 -X raw
And rebooted.
Now I get ~8.5ms delay. Under 10ms!
I think it would be interesting to have a file with a set of default configurations already predefined in accordance with hardware. 
Try change the frames/period to a lower value (64, 32). If sounds chunks, pulps or clicks, then the value 128 are ok.
Also, check if the sample rate used (48000) is good for your audio interface (I’m not too sure about this step.)
https://libremusicproduction.com/articles/demystifying-jack-–-beginners-guide-getting-started-jack
That would be a nightmare to maintain. We could put a txt file in the /boot folder that lets people change the jack settings. Similar to what we do in OctoPi for OctoPrint.
If there are different settings for different hardware choices like soundcards, it’s not that hard to implement in the webconf.
I do not own a Zynthian, but I remember that exists a page in webconf for manually changes the audio interface configuration.
My idea is something like a checkbox/select/dropdown box for the user select your audio interface. Also, if the user finds it necessary, you can change some of the default parameters loaded in the select.
The default configurations could be in a repository only for this purpose, so that it would be easy for people to suggest default settings for new audio interfaces.
Webconf could load them directly from the internet, always getting the newest integrations with audio interfaces. Another possibility would be to make new configurations available from webconf updates.
Hey,
So I’ve been using this for a while, and its awesome, its stage-quality latency. But there is something that is driving me crazy - mod-ui’s interface hangs. it hangs and it takes forever. I suspect its because its using tornado as its webserver, which has a single thread per process. @jofemodo Is that something we can change? Why are moddevices using tornado?
Difficult to change. The MOD-UI is strongly based in tornado server.
MOD-UI guys use tornado in its MOD-DUO device and i think they use a RT kernel. I don’t have a MOD-DUO unit, but @C0d3man have one and could say if the Web-UI performs well with it. I suppose yes.
In my preemp-kernel zynthians, MOD-UI runs quite smoothly. It takes a little bit to charge the plugin list (it’s large), but after that is fluent and very usable.
Regards,
The big question is: What else to use? Tornado is a really nice toolbox for web/websocket server. Changing means to rewrite MOD-UI.
The MOD-Duo uses a realtime kernel: Linux modduo 3.4.104-rt139-modduo #1 SMP PREEMPT RT Mon Sep 4 20:51:20 UTC 2017 armv7l GNU/Linux
MOD-UI runs without any problems on MOD-Duo… I just updated some plugins and creating some new pedalboards for my guitar.
Regards, Holger
Ok, will need to figure out what is causing it.
I have a real strong suspicion its dwc_otg, the RaspberryPi non-mainline-kernel USB host controller. Its good in messing things up like that.
See raspberrypi github issue: https://github.com/raspberrypi/linux/issues/2244
Current zynthian SD images use the default preemptive kernel (mainline). But the latest kernel versions 3.X and 4.X, have integrated lots of improvements from the PREEMPT_RT patch. Current kernel 4.9 works quite well when the needed latency is not less than 10 ms, and this is close to the latency we can reach in zynthian. If you try to reduce the latency under this value, (i.e. reducing the buffer size in the jackd options), you increase the risk of hearing clicks (getting x-runs in jackd). By using a PREEMPT_RT patched kernel we could reach smaller latencies and this is always interesting, but we have to pay a price: less performance.
Kind Regards