Re: package gcr breaks real-time settings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Sep 02, 2018 at 05:35:17PM +0200, David Runge wrote:

> Well, I guess you should've started complaining about that many years
> ago then ;-)

Maybe I should have... But if the standard answer is 'you can always
roll you own', then expressing any opinion or preference becomes sort
of pointless.

> > a set of users with common needs. So *all* features or permissions
> > that members of a group need should be made dependent on being a
> > member of that group and nothing else. This is entirely the opposite
> > of defining groups for one particular feature such as real time and
> > then requiring users to be a member of all of them.
> I don't exactly understand your logic here: Members of the realtime
> group *share* the same common needs. They ought to be able to acquire
> realtime scheduling for their processes.

The logic is: for audio you need access to audio devices, be
able to run real-time processes, and  be able to lock memory.
So create a group that has all these privileges. For any other
type of activities do the same. 

It's just a different way of organising groups. Instead of having  
groups for each single particular privilege, and require users to
be a member of a mix of them, define a single group which combines
whatever is required for some type of activity.

BTW, following  what I assume is your logic, the 'realtime' group
should be split in two, one for real time and one for memory locking.

> So, I'm unsure, what you're actually complaining about here.

I'm not complaining. Just preferred the way it was done before
(give the audio group whatever is needed for audio).

> > For what it's worth, I noticed that after upgrading to kernel 4.18 I
> > had to increase the memlock limit to avoid error messages almost all
> > audio applications.
> With what exact setup is that?
> Which components are involved?
> How do you configure your users and limits?
> Are you using the realtime-privileges group?
> Is your user in the realtime group?

> Ask a specific question and we'll try to give a specific answer.

I didn't ask any questions, only reported that I noticed something
related to memory locking had changed. Which seemed to be on-topic.

But to answer your questions:

* Archliux updated last two days ago.
* Jack, all audio apps using Jack (most of them my own).
* Using the 'audio' group, which has realtime and memlock
  entries in limits.conf.
* No
* No

Greetings from sunny Crete,

-- 
FA



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux