LinuxMusicians

xruncounter is very useful, thanks once more for the great job Tramp! And thanks merlyn + Drumfix for the tips about buffersizes and circles: after the tenth read this is finally making it through my thick skull ;-) So let's join the party: Here are some preliminary results on my 5+ y old notebook (...

No idea what is going on in your case, but that's probably worth reporting:
https://ardour.org/how_to_report_a_bug

Edit: Don't forget to read this as well, or you might end up disappointed.
https://community.ardour.org/support_expectations

For Arch users, here's a quick & dirty pkgbuild:
https://aur.archlinux.org/packages/kapitonov-plugins-pack-lv2-git

Ah, ok. I see very well where's you've been with those resamplers. I'm not going down that rabbit hole again (at least in the current state of technology) - life is just too short ;-) If the need really arise, I'd rather drop Guitarix and use my analog signal chain (I hope Tramp doesn't read this :D...

Sorry, I meant latency compensation rather that synchronization. But actually in your case it should be exactly the same as recording live guitar straight into a DAW, so nevermind. The resampling however does happen, since you go out of the Guitarix soundcard to the qtracktor soundcard using analog ...

Very nice ;-) I tried it as well a while ago, but with a single audio interface and that didn't go very well: I tried to use Zita-ajbridge to connect both jack instances (possibly also with a loopback, I don't remember very well). The outcome was mostly a flock of xruns - which defeats the original ...

Interesting results. Even at 540 us worst case latency the stock kernel does quite ok'ish for audio. Regarding those RT results with one core acting up: did you try to run the RT cyclictest with 3 cores? I'm wondering if sacrificing one core wouldn't actually help. It could be also a matter of RT pr...

It's CPU1 (the green line) that's letting the side down. :) The other three CPUs have a really good maximum latency -- around 50 microseconds. That's 0.05 milliseconds. It's interesting that CPU1 is so much worse than the others. Makes you wonder if there's anything tied to CPU1. If there's somethi...

I found also (empirically) that 4.19 RT is exceptionally good, but I have unfortunately not much time to join the benchmark fest. Looking at the results from the old threads on LM, it seems we are getting better: most of the results 2y ago were around 150us, now we're reliably getting below 100us - ...

Yeah, Nvidia + RT is not the easiest going combo for audio (although it seems to be working for some people). But it is not up to Arch to delay upgrades to support proprietary drivers - rather the opposite ;-) Anyway, if you want to pitch Linux-ZEN against the latest stock or RT, why not run a few b...

I think the Archlinux zen kernel is the way to go. Another plus is that it uses the newer I/O schedules like kyber/mq-deadline/bfq for better multi read/wrrite performance on HDD's. This kernel also has optimized the RCU timer threshold setting for more responsiveness. Attached is a zip I created t...

Gimmeapill do you not disable obviously irrelevant stuff in your kernel config? I used to be able to build a trimmed down one in about 10mins on my old core2duo. Yes, I used to, but this became over time a lot more pain than it is worth. I also used to build the spartan way with "make localmod...

...and in the meantime, look what just made it to the AUR: linux-rt 4.19.10 You can install a pre-built RT kernel by adding this unofficial user repository. I prefer to build stuff myself in a clean chroot rather than use third party repos whenever possible, but it is true that 4.19 RT did take a s...

@merlyn: thanks the precisions, I never looked too far into the stock Arch kernel. I should have made more clear that stock Arch <> vanilla, but anyway this is true for more or less any distro. ...and in the meantime, look what just made it to the AUR: linux-rt 4.19.10 https://aur.archlinux.org/pack...

Cool, thanks for the update!