Ardour vs REAPER vs Bitwig Studio vs Tracktion

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? :slight_smile: (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

(from Workflow | Libre Music Production step 1: The Advantages of Choosing an Audio Orientated Linux Distribution)

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).

But if I didn’t use threadirqs, in the case of Ardour wouldn’t I still have an “inversion” between Ardour’s high RT priority and my sound device?

In that case the only process with rt privileges would be Ardour, and there’d be no issue.

However 64/48kHz ~= 1.3ms IRQ scheduling of the USB ALSA driver would likely not work reliably (but 64 * 3 / 48k might).

1 Like

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… :slight_smile:

I’m wearing headphones :wink: 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.

1 Like

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.

3 Likes

Is that set as default, or do we have to set it manually?

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.

The Arch Linux realtime package, sets these permissions, alternatively check out ardour/tools/udev at master · Ardour/ardour · GitHub and copy 99-cpu-dma-latency.rules to /etc/udev/rules.d/.

1 Like

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.

1 Like

Yes, it is indeed very hardware dependent.

In case of @bachstudies 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.

1 Like

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.