Hi,
I see in the @autostatic new and very nicely improved RT quick config scan that there is some sort of Ardour udev rule for better scheduling performance (or something like that… I’m in a hurry today). Can somebody point out to me where that is…? I’d like to integrate it into the base AVL config next time around…
TIA!
From what I can tell rtqcs checks if /dev/cpu_dma_latency is witable by the current user.
If not it points to ardour/tools/udev at master · Ardour/ardour · GitHub and advises to copy 99-cpu-dma-latency to /etc/udev/rules.d/ and reboot.
You have to be in the audio group to gain write privileges.
Then Ardour can, presumably, set that value to 0 to “disable some power management frequency and voltage scaling depending on cpu hardware capabilities”.
A value of 0 seems to tell the CPU not to enter the deep sleep C0 state.
Interestingly enough my Ubuntu 20.04 PC has cpu_dma_latency set to
2000000000 but my openSuse 15.3 has it at 689062
We certainly do never advice that 
sudo udevadm control --reload-rules
sudo udevadm trigger
udevadm info -a -n /dev/cpu_dma_latency
but yes, Preferences > Performance does check and informs if /dev/cpu_dma_latency is not writable.
See also Ardour vs REAPER vs Bitwig Studio vs Tracktion - #57 by x42
–
PS. just writing a value in there does not help. An application needs to keep the file open for the setting to have have any effect, like e.g. cpudmalatency.c · GitHub
I know; I was citing the output from rtcqs.
And “reboot” is a lot easier to remember than the three lines you suggested
Robin is right, thanks for that. I’ll update rtcqs and remove the reboot part.
For a system that is very much geared to Ardour/Mixbus would you recommend incorporating all of those udev rules?
Yes, I would.
The other udev rules grant audio-users permissions to control-surfaces. It does not hurt to include those, even if a given user does not have a given device.
Great!
Will be in the next ISO update, whenever that is…
Thanks Robin! Glen, I just released a new version, with fixed CPU DMA latency advice: Releases - rtcqs - Codeberg.org
As a a avLinux user do I need to run these?
The goal is to grant your user permissions to prevent the CPU from sleeping, because that can improve reliability when working with low latency audio.
Future versions of AVLinux will have this set up, but for now you have to create a config file and then apply the change.
Save the file ardour/99-cpu-dma-latency.rules at master · Ardour/ardour · GitHub to /etc/udev/rules.d/ (requires root permissions) and then either reboot or restart the udev damon.
One way to accomplish this is by running
curl -s https://raw.githubusercontent.com/Ardour/ardour/master/tools/udev/99-cpu-dma-latency.rules | sudo tee /etc/udev/rules.d/99-cpu-dma-latency.rules
sudo udevadm control --reload-rules
sudo udevadm trigger
After that Ardour will by default ask the CPU to not enter deep sleep states as long as Ardour is running. See also Ardour > Preferences > Performance > Power Management, CPU DMA Latency.
Ardour picks the lowest non zero value by default.
Setting it to zero (no CPU idle) may cause some laptops to heat up, and thermal throttle performance (which is counter productive), but may be fine with desktop system. You can check CPU states and temperature with tools like i7z or s-tui.
On my system the lowest non-zero value is 2 usec which is perfectly fine.
Thank you Robin for taking the time to explain this in detail I should be able to get this done now without breaking anything.lol
After Ardour stops running, is the value reset to the value in effect before Ardour was started? Or is it lower from that point on?
The setting is only applied if an application is running and has an open file-descriptor for /dev/cpu_dma_latency. If more than one process has a valid filedes, the lowest value requested by any running process is used.
So yes, as soon as Ardour exits, the system behaves just like Ardour never requested a different value.
See also the PS at Ardour scheduling udev rule thingie? - #3 by x42 above.
You can query the currently active value by doing a hexdump of /dev/cpu_dma_latency. Note the value is little endian (swap the 8byte pairs), the unit is microseconds
e.g.
$ xxd /dev/cpu_dma_latency
00000000: 6745 2301
$ printf %d 0x01234567
19088743
Hi, AVLinux or general question… are there some bits I can flip to enable better USB performance (at the risk of deteriorating other qualities of service), and a way to flip them back? When I am doing backups to USB (i.e. not doing any audio/heavy-cpu-lifing), it can just sit there and look at me blankly as my cat does. Looking for a “heavy-duty I/O mode” vs my “heavy-duty low-latency mode”. Thanks!
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.