Moderators: MattKingUSA, khz
On Fedora when I run this script I get ...
[ WARNING ] Power management can't be controlled from user space, the device node /dev/cpu_dma_latency can't be accessed by your user. This prohibits DAWs like Ardour and Reaper to set CPU DMA latency which could help prevent xruns. For enabling access see https://wiki.linuxaudio.org/wiki/system ... _interface
However that link seems to be empty. Is there anywhere else where its documented for this step?
What happened to that Wiki?
That script was flawed from the beginning. You can’t rely on it for everything. Use it to get ideas as to what “may” be a potential areas for improvement, but don’t expect more. For example, some distros want you to add a group for real time limits and memlock, and then add yourself to that group. Some distros use “Audio” as the name for the real time group. Other distros use “Realtime” as the name for the group. Pipewire recommends a group named “Pipewire”. Some distros don’t give an assigned name, and you are expected to define your own group name and assign your limits and memlock to that.
Unless things have changed, I believe rtcqs looks for a group called, “Audio”. That means that it will fail that check if the group in your distro is named anything other than “Audio”. With 600+ distros available, it is highly unlikely that the script could catch every realtime group name, even if the developer tried to add the most common names.
I’m sure there are other possible problems with the script, but that is the one that I am most aware of. A developer can only do so much within the commonly changing world of Linux. That’s why I say use it for suggesting tuning possibilities, but don’t assume it is the final word on what is right or wrong in your system.
@Audiojunkie
Unless things have changed, I believe rtcqs looks for a group called, “Audio”. That means that it will fail that check if the group in your distro is named anything other than “Audio”. With 600+ distros available, it is highly unlikely that the script could catch every realtime group name, even if the developer tried to add the most common names.
rtcqs does an actual capabilities check, not a check for a specific group membership. The text at the link it produces actually talks about the fact that the name might differ, and mentions both audio and realtime (except that the linked page is now empty: odd, as I was using it on Monday without issues while configuring a new system).
The link that @crustypants referenced was similarly helpful: in addition to explaining the concept, it included a link to @x42's udev script to allow user-space programs like Ardour and Reaper to set CPU DMA latency (but of course, it is missing at time of posting as well).
The system config page at linuxaudio.org was down recently and @autostatic fixed it after I mentioned it. Maybe a similar issue has reared its ugly head again.
tseaver wrote: ↑Thu Mar 21, 2024 1:28 am@Audiojunkie
Unless things have changed, I believe rtcqs looks for a group called, “Audio”. That means that it will fail that check if the group in your distro is named anything other than “Audio”. With 600+ distros available, it is highly unlikely that the script could catch every realtime group name, even if the developer tried to add the most common names.
rtcqsdoes an actual capabilities check, not a check for a specific group membership. The text at the link it produces actually talks about the fact that the name might differ, and mentions bothaudioandrealtime(except that the linked page is now empty: odd, as I was using it on Monday without issues while configuring a new system).The link that @crustypants referenced was similarly helpful: in addition to explaining the concept, it included a link to @x42's
udevscript to allow user-space programs like Ardour and Reaper to set CPU DMA latency (but of course, it is missing at time of posting as well).
This wouldn’t be the first time I misunderstood something! 
Thanks for the info! I stand corrected! 
I'm glad to see that the reference page is re-populated.