Trouble With Admin Rights

[choice]

having trouble getting admin rights to run renoise with realtime priority, keep getting a fuzzy bzzzrt sound.

i know this was changed due to user request since b1, so

if i run renoise as root it’s clear like it should, but my vst_path is in my user home like everything else, it’s much simpler running renoise from my user.

so i went through to look at my user’s rights and i have administrator on my user, which is odd.
cuz, it should get the rt right?

[choice]

will try running with jack>alsa

[vvoois (vV)]

@choice

so i went through to look at my user’s rights and i have administrator on my user, which is odd.
cuz, it should get the rt right?

That might depend, which distribution are you using?
Some distribution seem to apply crippled admin rights to users that have admin status.
If you installed Renoise system wide (sudo ./install from the renoise setup folder) and start it as “sudo renoise” then it should start using root access.

If it does not get high priority by default, using the sudo command to change the priority is the usual way to go.
i have no idea if this can be configured somewhere but some linux guru might be able to supply a helping hand here.

[preglow]

Using the root account to gain realtime privs is a sub-optimal solution, An altogether better way is utilizing PAM, which most, if not all, newer Linux distros support. In this scheme, you just edit /etc/security/limits.conf to give any other group access to realtime scheduling. I add these lines:
@audio - rtprio 99
@audio - memlock 250000
@audio - nice -10
This gives elevated realtime scheduling and process priority privileges to the ‘audio’ group, which you have to add your user to.
The ‘memlock’ line decides how much memory you can lock, ie. make sure isn’t swapped to disk, and you might want to tweak this number. I’m no PAM expert, but the above works fine for me.

[choice]

thanks for the replies!
Ubuntu is more of a beast than i expected.
5 different ways to do the same thing.
but,
only 1 True way to actually do it & have it work!
getting much different than i remember, when you could do things a million different ways and each work out.

[preglow]

@NeuRoTiX

Does this mean that you, as a member of the “audio” group, will run every program with that privileges? Or mean that you’ll run with that privileges only the programs which are owned by the “audio” group?

I think that if the first question is true, you’ll put your system under many risks: not only security issues but also running simple programs could lead to freezing the system… not all the software is made to run realtime.

If the first isn’t true but the second is, so you should change the ownership of the renoise executable.

As far as I know, it applies to users, not files/programs, so it lets all programs run by a user in a given group request realtime privs. It doesn’t mean all programs run with realtime scheduling, just that they can ask for it. If it’s not designed to run realtime, it won’t.
Yes, this is bad, but if Linux had better latencies we wouldn’t have to mess around with realtime scheduling privs in the first place. It’s a necessary evil for now, and if you ask me, it sure beats running stuff as root, which leaves a security hole the size of a house. Not saying that Renoise is exploitable, of course, just saying it’s a bad habit and should be done as little as possible.