Bug 14426

The real problem is that professional audio needs realtime, while Mageia does not give realtime perms to normal users.

How to handle this well? Maybe an option when creating user account?

Fedora patches create a group with RT, and the README says that jackit users should be members of that group. This is not so simple, AVLinux distro directly gives RT to any user.

I think we should give RT to every users as soon as jackit is installed, maybe with an urpmi README alerting on that.

(In reply to José Jorge from comment #1)
> The real problem is that professional audio needs realtime, while Mageia
> does not give realtime perms to normal users.

Exactly
> 
> How to handle this well? Maybe an option when creating user account?

That would involve the installer :\

> 
> Fedora patches create a group with RT, and the README says that jackit users
> should be members of that group. This is not so simple, AVLinux distro
> directly gives RT to any user.
>

AVLinux is dedicated to audio so that's understandable, but not sure the security implications are so desirable in Mageia

> I think we should give RT to every users as soon as jackit is installed,
> maybe with an urpmi README alerting on that.

Users of jackit may not exist when jackit is installed.

I was thinking about creating a 'realtime' group on jackit install and a script wrapper for the jackit binary that uses an ACL to add the user running jackit to the 'realtime' group if not already a member.
Any user would then be added to the 'realtime' group on running jackit, but not otherwise.
The script would pass jackit parameters straight through to the the real jackit binary located outside $PATH.

Any thoughts?

> I was thinking about creating a 'realtime' group on jackit install and a script wrapper for the jackit binary that uses an ACL to add the user running jackit to the 'realtime' group if not already a member.

That sounds crazy to me : will you remove the user from that group when stopping jackit?

Anyway, we need a solution as for now ardour is almost as hard to use as if it was not packaged, so let's test your idea...

(In reply to José Jorge from comment #3)
> 
> That sounds crazy to me 

Yes it probably is ;)
 
> Anyway, we need a solution as for now ardour is almost as hard to use as if
> it was not packaged, so let's test your idea...

For now I have added the realtime group creation to a test build of jackit and it now installs /etc/security/limits.d/95-jack.conf

http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/SRPMS/jackit-1.9.10-5.mga5.src.rpm

With this version all that is required from the user is to do the following which can be added in a README.urpmi in ardour3

su
usermod -a -G realtime YourUserName
log out
log in

I have tested this in a VM and it seems OK.

An alternative would be a small setup script that would do the same as the above.

WDYT?

@dmorgan any thoughts on this? (I know it's your package - I'm just trying to help)

Adding a user to a group can also be done in userdrake, the only issue I can see there is that the list of groups is rather long.

To make it anywhere user friendly this way the warning/error message from jackit or ardour would need to tell the user exactly what to do (usermod and/or userdrake).

CC: (none) => cjw

(In reply to Christiaan Welvaart from comment #5)
> Adding a user to a group can also be done in userdrake, the only issue I can
> see there is that the list of groups is rather long.

That's why I prefered a default group for all simple users, which gets RT capablities when jackit is installed.

But this means that any user is created with a secondary group 'default'...

Is there a way we could give the "console" user (one logged into the machine physically) RT access like we give them access to certain devices already?

(In reply to David Walser from comment #7)
> Is there a way we could give the "console" user (one logged into the machine
> physically) RT access like we give them access to certain devices already?

Probably but I don't know where this would be done, and I understand this introduces some security concerns.

Maybe adding something like this to ardour3 (along with the realtime group creation in jackit as above) would solve this immediate issue:

%install
cat > README.urpmi <<EOF
You will need to log out and log in before using Ardour3
...and maybe add a security warning here...
EOF

%pre
gpasswd -a $(users|cut -d' ' -f1) realtime

%postun
gpasswd -d $(users|cut -d' ' -f1) realtime

This should work for a single user, but it would be much better if the logged in user was added to the group automatically.

However, would he then have to log out/in again to activate it? - endless loop :\

If someone has physical access to the machine, it's kind of hard to introduce additional security concerns.

I don't know the current mechanism for doing this, it used to be pam_console, but I think it has changed a couple of times since then.  It's hard to keep up with.

Seems to work. Ardour3 runs OK starting directly or after using qjackctl to start jack:

[baz@jackodesktop x86_64]$ sudo urpmi ardour3-3.5.403-2.mga5.x86_64.rpm

installing ardour3-3.5.403-2.mga5.x86_64.rpm
Preparing...                     #######################################################################################################
Adding user baz to group realtime
      1/1: ardour3               #######################################################################################################
      1/1: removing ardour3-3.5.403-1.mga5.x86_64
                                 #######################################################################################################
----------------------------------------------------------------------
More information on package ardour3-3.5.403-2.mga5.x86_64
You will need to log out and log in before using Ardour3
...and maybe add a security warning here...

----------------------------------------------------------------------


[baz@jackodesktop ~]$ sudo urpme ardour3

removing ardour3-3.5.403-2.mga5.x86_64
removing package ardour3-3.5.403-2.mga5.x86_64
      1/1: removing ardour3-3.5.403-2.mga5.x86_64
                                 ########################################################################################################
Removing user baz from group realtime

FWIW, the "recommended" way to request realtime for specific threads these days is via rtkit. This is what PulseAudio uses too and it's simple and effective.... except that it doesn't quite work these days due to the "not quite ready yet" nature of the kernel side of the big cgroup rewrite that's still in progress.

There are probably some really nasty hacks that I can cobble together to make rtkit work again in the short term until the rest of that stuff is ready. I'll add it to my list to look into that.

In the meantime, can you confirm that jack is actually using rtkit to request realtime privs?

CC: (none) => mageia

(In reply to Colin Guthrie from comment #11)

> In the meantime, can you confirm that jack is actually using rtkit to
> request realtime privs?

It seems not, so maybe it should.

Any progress status for this issue?

Whiteboard: (none) => MGA5TOO

Hi Colin, did you get anywhere with this?
I'm just looking at updating ardour and realized when testing that this is still an issue.

Adding neoclust to cc as he is now jackit maintainer.

CC: (none) => neoclust

@Colin
ping ;)

This is still going nowhere as I don't want to break jackit by maybe making it do something undesirable.

Any chance you could take another look?

Fixed in Cauldron

Status: NEW => RESOLVED
Resolution: (none) => FIXED