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):
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
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.
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.
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.
Thanks @jofemodo - all understood. I thought I had seen reference to using RT so was looking for its implementation. (That is why I installed ZynthianOS.) I will have a play and see if I can build it and do some analysis. My previous experience with RT was in minimising latency. It will be good to see if we can get similar performance with lower latency with RT. I will report back.
Do you think it would be easy to generate a “dual-kernel” image?
So you could choose what kernel do you want to use from the webconf tool. Not everybody want a RT kernel. Lower latency has a price: lower performance.