Surely that’s the real issue - rather than people obsessing about IRQ priorities to win bragging rights for achieving the lowest latency for individual hardware devices - important thought that may be if you want to spend more time tweaking settings than actually making music. I would class the original priority inversion issue as a bug with ardour. I would expect that the default application configuration should be “reliable, and gets you where you need to go” rather than tuned to win races.
(Apologies in advance for the rant, but I’m on something of a mission to try and spread the word that you really no longer need to tweak linux in order to do audio - sure, you can and that’s a good thing, if you want to, but there is a popular misconception that you have to - and that this involves all manner of command line shenanigans. It doesn’t and you don’t need to. A stock install will ‘get you where you want to go’ at least as well if not better than other operating systems. Unfortunately every time I mention this it seems to trigger a discussion about how you only have to edit this or that file once - it may or may not be where it was last time, you could have to change permissions, but it might be systemd dependent or whatever but once you’ve installed a custom IRQ tweak tool and optimised your kernel configuration everything will be fine… pffft - you don’t need to )
I’m currently running an experimental predictive quantum entangled negative-latency driver which has captured all the combinations of notes I’m ever likely to play during my life - simultaneously - it then simply collapses to the appropriate state required to output the selected one a matter of milliseconds before I actually play it
Ardour cannot do anything about users not configuring their system correctly.
This issue happen if a user manually adds the “threadirqs” kernel boot option, but does not install a tool to manage those IRQ threads. Kernel IRQ threads use default priority 50.
Reaper inherited the priority from JACK, which was also configured by the user (default is 70).
So does this mean the issue would not have arisen if a user simply installed e.g. a standard Ubuntu distro and made no custom tweaks? (Do you see what I’m getting at here…)
It is an unfortunate fact that much of the troubleshooting on audio software forums and IRC channels ends with a similar conclusion, that it is not the software that’s the problem but rather how the users distro is set up
It depends on the use. For much studio recording where the monitoring is done outside the DAW, latency is not an issue. However, if the player is using the internal synth for monitoring or guitar effects in the DAW to help them play with the proper ferocity, latency is important and a generic ubuntu kernel will not get many users what they want.
I would tend to agree but might call it an “oddity” versus a bug. There seems to be no reason to have Ardour’s RT priority so high compared to other DAWs. As I said, all the numbers are relative and this is why I’m able to run REAPER with RT priority 5 with absolutely zero issues. Given sound devices seem to default to 50, it makes sense to have Ardour lower than that by default. Would it make sense to have an accessible preference option for those who absolutely must have a higher value?
Right, any number between 1 and 49 would have the same result. I expect you’ve used JACK with priority of 10 (which results in the default application callback to be 5).
If you use threadirqs you should elevate the soundcard’s IRQ priority as well as the audio application callback to above 50. Otherwise you might just as well not use that feature (and no have this issue in the first place).
Alas, even with everything now set up optimally with regards udev-rtirq, while improved in Ardour, I still can’t get the same level of performance as I can with REAPER et al. It is no longer night and day but the difference is occasional audio glitches even at 128/3 vs none in REAPER at 64/2 while running what I would consider quite intensive reverb plugins. I suppose it is what it is at this stage.
There is a popular idea that you should always try to get the lowest possible latency. I always try to set the highest possible latency consistent with acceptable performance for the task. My use case is probably different from those who use mainly software instruments, in that when I do record, I’m playing / recording guitar through an amp mic’d into the DAW in a very ‘traditional’ recording setup - so I’m not overly dependent on ‘in the box’ monitoring or effects. But surely 64 samples is really in the realm of ‘move closer to the speakers’ if it makes that much difference…
I’m wearing headphones All I can say is that I can tell the difference between 64 and 128 when playing harpsichord VSTi but both are acceptable.This all said, watch this space as I believe the devs will soon look into potential optimizations based on some of their own side-to-side comparisons with DSP in REAPER vs Ardour.
As a final note… Since Ardour 6.7-124 there is now an option in Preferences > Performance to request a min cpu-dma latency. This prevents the CPU from reaching deeper idle states which can significantly improve performance.
It is off by default because there is also the possibility that the CPU may overheat if it never enters deep sleep states, and the system may be thermal throttled (or overheat).
Furthermore the user needs to have permissions write to /dev/cpu_dma_latency.
How is it a win for performance if I enable an option which eventually causes my CPU to overheat and be thermally throttled anyway (assuming nothing else bad happens as a result) ?
My understanding is that the overheating depends on the system (CPU, chipset, whatever), so maybe many setups will be OK, but it’s safer to avoid it by default if you don’t know.
In case of @anon60445789 requesting a low cpu-dma latency is what made all the difference!
Likely the CPU was unused for relatively long time, went into C3 or C6 sleep (both turn off bus clocks) and re-enabling hw clock takes too long.
Requesting the lowest non-zero latency can be sufficient. That allows the CPU to reach C1, bit no deeper power-saving states. This can still limit the temperature.
On Intel CPUs sudo i7z is helpful to check.
PS. Compiling the Linux kernel (or Ardour) with constant 100% CPU usage of all cores can equally result in thermal throttling, but in that case the system will just compile more slowly. With audio it may result in dropouts.
Keep in mind that that is not supposed to happen. Only a few laptop systems which are notorious for having heat dissipation issues are likely affected. – and this is not Linux specific either.
)
All I can say is that I can tell the difference between 64 and 128 when playing harpsichord VSTi but both are acceptable.This all said, watch this space as I believe the devs will soon look into potential optimizations based on some of their own side-to-side comparisons with DSP in REAPER vs Ardour.