Realtime Kernel for Raspi

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?

Maybe this help
https://wiki.linuxaudio.org/wiki/jack_latency_tests

1 Like

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.

  1. 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:

  2. 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
1 Like

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!

2 Likes

I think it would be interesting to have a file with a set of default configurations already predefined in accordance with hardware. :thinking:

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.

1 Like

I do not own a Zynthian, but I remember that exists a page in webconf for manually changes the audio interface configuration.

image

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

Update, there is kernel 4.14 now. I need to get RealtimePi to work with it, there is a commit that breaks patching which I need to revert.

Yet another update

  1. I got kernel 4.14 patched, its being built
  2. So did the Rpi foundation , they pushed a realtime kernel branch, asked them on the forum what is going on: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=206750&p=1306688#p1306688
1 Like

Did we abandon plans to use a realtime kernel in zynthian? I would have thought it would be beneficial.

From the JackAudio documentation:

http://jackaudio.org/faq/realtime_vs_realtime_kernel.html

Of course, i’ve tested RT kernels (RT_PREEMPT patch) with zynthian, but i hadn’t see any measurable improvement. Moreover, by using the RT_PREEMPT code, you will reach CPU limits more easily because less CPU power is available for doing useful tasks (audio preccessing).

For understanding how RT-kernel can help us, you have to think in a “jackish” way. Jack Audio is the key part and if having a RT-kernel doesn’t improve jack performance, i don’t see any reason to change.

Of course, you are free to do your tests and share your conclusions. I’m not closed to changing to a RT-kernel, but i wouldn’t like to do it without having clear (with numbers!) the benefits and drawbacks.

Regards,