JACK and RT cgroups

classic Classic list List threaded Threaded
70 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

JACK and RT cgroups

Dhaval Giani
[Sorry for the resend. Did not realize the list is subscriber only]

Hey there,

I have been pointed out to http://jackaudio.org/linux_group_sched .

As a set of instructions,

No, setting up a new cgroup is not hard, and does *not* involve
concepts beyond a regular user. If you mess around with configuration
files, it is quite easy. Now, more likely than not, the systems that
exhibit this issue are having libcgroup installed. With libcgroup, we
create a default cgroup to trap every process in. At the time of
design, we did not look at trapping real time processes, so we did not
assign any realtime time to the default group. Now, I am not inclined
to change that because JACK is a special case and in most cases normal
users should not be launching rt processes and in case there is
someone else, they can explicitly provide those powers.

Now, coming to the question of what a normal user can do to resolve
this problem, there are three solutions for this problem,
a. Disable the default group from being created (I do not really recommend this)
b. Assign some rt_runtime to the default cgroup.
c. Have a jack cgroup and have the jack process moved there. (the most
complex, but I recommend this one for obvious benefits)

To do a)

in /etc/sysconfig/cgconfig add a line, CREATE_DEFAULT=no

To do b)

in /etc/cgconfig.conf

add in
group sysdefault {
 cpu {
cpu.rt_runtime_us = 500000;
}
perm{
task{
uid = root;
gid = root;
}
admin {
uid =root;
gid = root;
}
}

(forgive the formatting, I am missing my regular mailclient for gmail)

c. This is a bit complex, first you will need to define the jack group
in cgconfig.conf (like we defined sysdefault, with the owner being the
jack user))
Then add a line in /etc/cgrules.conf
<jack_user>:<jack_process_name> cpu <jack_group>

jack_process_name should be the parent process.

Setup cgred to startup at startup, and it should then move the jack
process to the right cgroup when it starts up (and I am assuming that
the jack_process will fork the new rt process).

Hope this helps, and do let me know if I can help more.

Thanks!
Dhaval
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK and RT cgroups

Tommaso Cucinotta-2
Il 15/12/2010 18:33, Dhaval Giani ha scritto:
> No, setting up a new cgroup is not hard, and does *not* involve
> concepts beyond a regular user.
Probably, people on this list were actually meaning "what a normal
Jack user has been thought to do for years as administrator on its
own system", i.e., setting properly the limits.conf file.
So, AFAICS, the real issue they're experimenting is that the existing
and probably widely known guidelines for letting unprivileged users
use Jack and other applications on Linux at RT priority do not work
anymore. So, people need to learn again, and why this is really
needed should be probably clearly stated out explicitly, along with
the explanation of what are the advantages of this new cgroups
set-up.

This might impact not only Jack users, but any user and developer
of applications exploiting RT prios on Linux. AFAICR this includes CD
burning software and don't know what else.
> to change that because JACK is a special case
see above: are u sure this is not affecting a huge base of users, contrarily
to what you're saying here ?
> and in most cases normal
> users should not be launching rt processes and in case there is
> someone else, they can explicitly provide those powers.
Please, think of the desktop/laptop users as well, not only workstations
administered by admin experts. For Jack users (i.e., live music players,
non-necessarily IT experts), it was common to launch jackd (and clients)
at RT prio, and they knew how to hack their Linux system in order to do
that. Now it is still possible but the way to do that changed abruptly.

My 2 cents.

     T.

--
Tommaso Cucinotta, Computer Engineering PhD, Researcher
ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy
Tel +39 050 882 024, Fax +39 050 882 003
http://retis.sssup.it/people/tommaso

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK and RT cgroups

Dhaval Giani
On Wed, Dec 15, 2010 at 6:49 PM, Tommaso Cucinotta
<[hidden email]> wrote:

> Il 15/12/2010 18:33, Dhaval Giani ha scritto:
>>
>> No, setting up a new cgroup is not hard, and does *not* involve
>> concepts beyond a regular user.
>
> Probably, people on this list were actually meaning "what a normal
> Jack user has been thought to do for years as administrator on its
> own system", i.e., setting properly the limits.conf file.
> So, AFAICS, the real issue they're experimenting is that the existing
> and probably widely known guidelines for letting unprivileged users
> use Jack and other applications on Linux at RT priority do not work
> anymore. So, people need to learn again, and why this is really
> needed should be probably clearly stated out explicitly, along with
> the explanation of what are the advantages of this new cgroups
> set-up.
>

Well, that is no reason to say "This is incredibly unfortunate for
people who want to run software like JACK" in the documentation. It is
not. It is quite easy to do so, and there are just a few one time
setup steps that solve the issue permanently.

> This might impact not only Jack users, but any user and developer
> of applications exploiting RT prios on Linux. AFAICR this includes CD
> burning software and don't know what else.

well, any application that uses RT priorities is a special case, and
should take appropriate care.

>>
>> to change that because JACK is a special case
>
> see above: are u sure this is not affecting a huge base of users, contrarily
> to what you're saying here ?

So I did a ps -eLf | grep jack and the only thing I got was the grep.
I am not so sure how many people it affects. We would have had bug
reports come in if it were a significant number.

>>
>> and in most cases normal
>> users should not be launching rt processes and in case there is
>> someone else, they can explicitly provide those powers.
>
> Please, think of the desktop/laptop users as well, not only workstations
> administered by admin experts. For Jack users (i.e., live music players,
> non-necessarily IT experts), it was common to launch jackd (and clients)
> at RT prio, and they knew how to hack their Linux system in order to do
> that. Now it is still possible but the way to do that changed abruptly.
>

Well, I am sorry about that. We really cannot help it. These features
have been discussed in the past, and they are in now. Also, turning
off these features is quite easy, and just needs one line in the
appropriate configuration file. (Though I still feel it should be
setup properly). Also, something that we have been working on is to
allow an application to specify its own cgroup configuration and load
it at runtime. JACK developers could potentially do that, thereby no
longer requiring the user to set it up.

Thanks,
Dhaval
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK and RT cgroups

Paul Davis
In reply to this post by Dhaval Giani
On Wed, Dec 15, 2010 at 12:33 PM, Dhaval Giani <[hidden email]> wrote:

> No, setting up a new cgroup is not hard, and does *not* involve
> concepts beyond a regular user. If you mess around with configuration
> files, it is quite easy. Now, more likely than not, the systems that
> exhibit this issue are having libcgroup installed. With libcgroup, we
> create a default cgroup to trap every process in. At the time of
> design, we did not look at trapping real time processes, so we did not
> assign any realtime time to the default group. Now, I am not inclined
> to change that because JACK is a special case and in most cases normal
> users should not be launching rt processes and in case there is
> someone else, they can explicitly provide those powers.

The problem is that JACK is not the only process that needs to be
treated as special. Moreover, you're whole assumption that "in most
cases normal
users should not be launching rt processes" is completely wrong. The
JACK community has spent nearly 8 years trying to get the kernel
community and userspace tools to give regular users access to the
facilities needed to get their work done. We were almost there, via
PAM and limits.conf, when this issue came up. Its a major regression
for our user community.

> Now, coming to the question of what a normal user can do to resolve
> this problem, there are three solutions for this problem,
> a. Disable the default group from being created (I do not really recommend this)
> b. Assign some rt_runtime to the default cgroup.
> c. Have a jack cgroup and have the jack process moved there. (the most
> complex, but I recommend this one for obvious benefits)

Its not just one JACK process. Its all JACK clients, the names of
which are not known in advance. JACK is a server client system that
may involve many different applications.

What was written on the page at jackaudio.org was written out of
ignorance about how to set up cgroups. It was written as a page for
JACK end users, for whom the type of instructions you listed would be
reason enough to simply walk away.

As Torben noted earlier in a related thread, although the kernel
mechanisms for RT_GROUP_SCHED have been in place for a while,
userspace is just not ready for it unless you consider it a tool only
for experienced system admins who are probably running some kind of
compute server. Its existence on a machine where a normal user
requires SCHED_FIFO to be able to do reliable low latency audio is
really a mistake given the user space tools currently available.

--p
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK and RT cgroups

Fons Adriaensen-2
In reply to this post by Dhaval Giani
On Wed, Dec 15, 2010 at 06:33:44PM +0100, Dhaval Giani wrote:

> To do a)
>
> in /etc/sysconfig/cgconfig add a line, CREATE_DEFAULT=no
>
> To do b)
>
> in /etc/cgconfig.conf
>
> add in
> group sysdefault {
>  cpu {
> cpu.rt_runtime_us = 500000;
> }
> perm{
> task{
> uid = root;
> gid = root;
> }
> admin {
> uid =root;
> gid = root;
> }
> }

Would this mean all processes are running as for root ??
 

> c. This is a bit complex, first you will need to define the jack group
> in cgconfig.conf (like we defined sysdefault, with the owner being the
> jack user))
> Then add a line in /etc/cgrules.conf
> <jack_user>:<jack_process_name> cpu <jack_group>
>
> jack_process_name should be the parent process.
>
> Setup cgred to startup at startup, and it should then move the jack
> process to the right cgroup when it starts up (and I am assuming that
> the jack_process will fork the new rt process).

No, jack clients are not forked by Jack but started just as any other
app: from the command line, a script, or a desktop menu or icon. They
start up as normal applications, may become a Jack client at some point,
and could in fact attach/detach from Jack any number of times the choose.
They may also need to create additional RT threads besides the one created
for them by libjack.

To be really as useful as the current solution using limits.conf,
anything based on cgroups should just assign RT rights to a user
or a group of users, without requiring administration or special
code for each and every application. This is more like b).

Ciao,

--
FA

There are three of them, and Alleline.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK and RT cgroups

Dhaval Giani
In reply to this post by Paul Davis
On Wed, Dec 15, 2010 at 7:03 PM, Paul Davis <[hidden email]> wrote:

> On Wed, Dec 15, 2010 at 12:33 PM, Dhaval Giani <[hidden email]> wrote:
>
>> No, setting up a new cgroup is not hard, and does *not* involve
>> concepts beyond a regular user. If you mess around with configuration
>> files, it is quite easy. Now, more likely than not, the systems that
>> exhibit this issue are having libcgroup installed. With libcgroup, we
>> create a default cgroup to trap every process in. At the time of
>> design, we did not look at trapping real time processes, so we did not
>> assign any realtime time to the default group. Now, I am not inclined
>> to change that because JACK is a special case and in most cases normal
>> users should not be launching rt processes and in case there is
>> someone else, they can explicitly provide those powers.
>
> The problem is that JACK is not the only process that needs to be
> treated as special. Moreover, you're whole assumption that "in most
> cases normal
> users should not be launching rt processes" is completely wrong. The
> JACK community has spent nearly 8 years trying to get the kernel
> community and userspace tools to give regular users access to the
> facilities needed to get their work done. We were almost there, via
> PAM and limits.conf, when this issue came up. Its a major regression
> for our user community.
>
>> Now, coming to the question of what a normal user can do to resolve
>> this problem, there are three solutions for this problem,
>> a. Disable the default group from being created (I do not really recommend this)
>> b. Assign some rt_runtime to the default cgroup.
>> c. Have a jack cgroup and have the jack process moved there. (the most
>> complex, but I recommend this one for obvious benefits)
>
> Its not just one JACK process. Its all JACK clients, the names of
> which are not known in advance. JACK is a server client system that
> may involve many different applications.
>

Are they all forked by the main jack process? How many threads are
privileged to RT priority?

> What was written on the page at jackaudio.org was written out of
> ignorance about how to set up cgroups. It was written as a page for
> JACK end users, for whom the type of instructions you listed would be
> reason enough to simply walk away.
>

Even an instruction as simple as

open /etc/sysconfig/cgconfig and change the line which says
DEFAULT_CGROUP=yes to DEFAULT_CGROUP=no ?

seriously? I see so many ubuntu workarounds which have much more
complicated steps, and people are quite happy to follow them.

> As Torben noted earlier in a related thread, although the kernel
> mechanisms for RT_GROUP_SCHED have been in place for a while,
> userspace is just not ready for it unless you consider it a tool only
> for experienced system admins who are probably running some kind of
> compute server. Its existence on a machine where a normal user
> requires SCHED_FIFO to be able to do reliable low latency audio is
> really a mistake given the user space tools currently available.

Right. So here is my question. What do you think can be done to
improve the current state of the tools? Jan, Ivana and Balbir (on the
cc) are also involved in the libcgroup project and we are very much
committed to improving the state of tools. However either we are
looking at the problem from a programmer's perspective or an
administrator's perspective. So what do you, as an end user need?
Would you be willing to help us out?

Thanks,
Dhaval
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK and RT cgroups

Dhaval Giani
In reply to this post by Fons Adriaensen-2
On Wed, Dec 15, 2010 at 7:04 PM,  <[hidden email]> wrote:

> On Wed, Dec 15, 2010 at 06:33:44PM +0100, Dhaval Giani wrote:
>
>> To do a)
>>
>> in /etc/sysconfig/cgconfig add a line, CREATE_DEFAULT=no
>>
>> To do b)
>>
>> in /etc/cgconfig.conf
>>
>> add in
>> group sysdefault {
>>  cpu {
>> cpu.rt_runtime_us = 500000;
>> }
>> perm{
>> task{
>> uid = root;
>> gid = root;
>> }
>> admin {
>> uid =root;
>> gid = root;
>> }
>> }
>
> Would this mean all processes are running as for root ??
>

No. Just that the owner of the cgroup is root. The special case about
sysdefault is that _anyone_ can attach to that group. (Which is not
the case with the root cgroup)

>> c. This is a bit complex, first you will need to define the jack group
>> in cgconfig.conf (like we defined sysdefault, with the owner being the
>> jack user))
>> Then add a line in /etc/cgrules.conf
>> <jack_user>:<jack_process_name> cpu <jack_group>
>>
>> jack_process_name should be the parent process.
>>
>> Setup cgred to startup at startup, and it should then move the jack
>> process to the right cgroup when it starts up (and I am assuming that
>> the jack_process will fork the new rt process).
>
> No, jack clients are not forked by Jack but started just as any other
> app: from the command line, a script, or a desktop menu or icon. They
> start up as normal applications, may become a Jack client at some point,
> and could in fact attach/detach from Jack any number of times the choose.
> They may also need to create additional RT threads besides the one created
> for them by libjack.
>
> To be really as useful as the current solution using limits.conf,
> anything based on cgroups should just assign RT rights to a user
> or a group of users, without requiring administration or special
> code for each and every application. This is more like b).
>

Well, that is also possible. I looked at a pid based grouping option
under the (wrong as it turns out) impression that the jack parent
thread would own all rt threads. But as I said, you can quite easily
create a cgroup and change its gid permissions to a group, and instead
of the <jack_user>:<process_name> cpu <jack group> line, add a
@<jack_group> cpu <jack_cgroup>

line which would do the exact same thing.

Dhaval

> Ciao,
>
> --
> FA
>
> There are three of them, and Alleline.
>
> _______________________________________________
> Jack-Devel mailing list
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK and RT cgroups

Paul Davis
In reply to this post by Dhaval Giani
On Wed, Dec 15, 2010 at 1:08 PM, Dhaval Giani <[hidden email]> wrote:
> On Wed, Dec 15, 2010 at 7:03 PM, Paul Davis <[hidden email]> wrote:

>> Its not just one JACK process. Its all JACK clients, the names of
>> which are not known in advance. JACK is a server client system that
>> may involve many different applications.
>>
>
> Are they all forked by the main jack process? How many threads are
> privileged to RT priority?

1 per process.

>> What was written on the page at jackaudio.org was written out of
>> ignorance about how to set up cgroups. It was written as a page for
>> JACK end users, for whom the type of instructions you listed would be
>> reason enough to simply walk away.
>>
>
> Even an instruction as simple as
>
> open /etc/sysconfig/cgconfig and change the line which says
> DEFAULT_CGROUP=yes to DEFAULT_CGROUP=no ?

that's adequate as a workaround to the while thing, yes.

> Right. So here is my question. What do you think can be done to
> improve the current state of the tools? Jan, Ivana and Balbir (on the
> cc) are also involved in the libcgroup project and we are very much
> committed to improving the state of tools. However either we are
> looking at the problem from a programmer's perspective or an
> administrator's perspective. So what do you, as an end user need?
> Would you be willing to help us out?

Well, RT_GROUP_SCHED doesn't offer anything to the pro-audio/music
creation community at all. It would be much easier for us if it just
wasn't there at all, and if it was there, if it had no side effects.
Turning of the default cgroup might be enough. But really, this is
something that neither JACK application developers nor JACK end users
have any reason to deal with.

Just parenthetically, JACK and many JACK applications also run on OS
X. Do you know what is needed to get access to realtime scheduling on
that system?

    setThreadToPriority(thread, 96, TRUE, 10000000);

that's it. It works on every OS X system, for every user. We don't
expect Linux to follow this behaviour - POSIX makes that hard enough
already, and its role as a server and multi-user platform make that
impractical. But I hope you can perhaps understand how incredibly
irritating it is that *just* as almost mainstream distros now finally
come with the mechanism to grant ordinary users SCHED_FIFO and memlock
without too much hassle (its taken more than 8 years to get there),
RT_GROUP_SCHED appears without any apparent appreciation for the
impact on what is probably the most widely used RT-scheduled
application "ecosystem" on Linux.

--p
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK and RT cgroups

Alex Stone
In reply to this post by Tommaso Cucinotta-2
Dhaval,
So as jack users (non-coders), with many of us having invested
hundreds and possibly thousands of hours testing for our modest
community, not to mention the most definitely thousands of hours of
sweat and toil put in by the all too few jack/RT coders who have
valiantly laboured most generously for like minded users in a shared
desire to have great, professional quality, audio/midi/video tools as
viable alternatives to proprietary locked in apps, we are being
reduced to a single label, entitled "Linux User" to satisfy a generic
perception of what someone, somewhere thinks is the definition of what
we "should" be using? Regardless of the limitations this imposes,
which is something we accuse proprietary OS's of?

I respectfully wonder if the team that made this decision are aware of
the number of jack/RT users that actually pass through our little
village, or if the decisions being made are in earnest pursuit of a
wider generic user base, are reflective of an honest misunderstanding
of just how important jack/RT apps and infrastructure are for linux
users who would rather enjoy the superb stability of linux as a viable
professional system, over the angst that goes with the "others".

I'm bewildered by the indifference to what i thought was a sizable and
significant chunk of the linux community. It seems i misjudged the
importance and superb performance of a jack based system, over the
rest.

Now it seems we have to start again, yes? Based on what seems ever
increasing perception that all non coding linux users
are......."generic".

Dhaval, i have no wish to offend you, but it looks as if you've posted
to us as some sort of apologetic afterthought. I appreciate you're in
a bit of a spot with this, but i hope you appreciate this will make
things more challenging for us, and make it even harder to encourage
new users into our village in the linux user community, when we will
have to walk fellow users though additional instructions to try and
get what we already had, and what was already challenging enough to
setup, for new initiates into the linux "way".

Are we really of so little significance in the wider linux world?

Regards,

Alex.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK and RT cgroups

Tommaso Cucinotta-2
In reply to this post by Dhaval Giani
Il 15/12/2010 19:11, Dhaval Giani ha scritto:

>
>>> c. This is a bit complex, first you will need to define the jack group
>>> in cgconfig.conf (like we defined sysdefault, with the owner being the
>>> jack user))
>>> Then add a line in /etc/cgrules.conf
>>> <jack_user>:<jack_process_name>  cpu<jack_group>
>>>
>>> jack_process_name should be the parent process.
>>>
>>> Setup cgred to startup at startup, and it should then move the jack
>>> process to the right cgroup when it starts up (and I am assuming that
>>> the jack_process will fork the new rt process).
>> No, jack clients are not forked by Jack but started just as any other
>> app: from the command line, a script, or a desktop menu or icon. They
>> start up as normal applications, may become a Jack client at some point,
>> and could in fact attach/detach from Jack any number of times the choose.
>> They may also need to create additional RT threads besides the one created
>> for them by libjack.
>>
>> To be really as useful as the current solution using limits.conf,
>> anything based on cgroups should just assign RT rights to a user
>> or a group of users, without requiring administration or special
>> code for each and every application. This is more like b).
>>
> Well, that is also possible. I looked at a pid based grouping option
> under the (wrong as it turns out) impression that the jack parent
> thread would own all rt threads. But as I said, you can quite easily
> create a cgroup and change its gid permissions to a group, and instead
> of the<jack_user>:<process_name>  cpu<jack group>  line, add a
> @<jack_group>  cpu<jack_cgroup>
>
> line which would do the exact same thing.

Yes, but AFAICR, there's still a problem: Jack not only pushes the threads
created by libjack to RT (for which it is easy to identify the Linux TID for
attaching it to the group), but it also allows the application clients
to pass
a *pthread_t* value through the API, in order to raise its priority to
RT. So, I guess now there's no way to recover the Linux TID from the
pthread_t, so such a feature wouldn't work anymore.

I cannot defend that feature with its own current API, as we used to
have the same problem when applying the deadline-based scheduler
to Jack. The only practically working hack we found to fix that, was
the use of an LD_PRELOAD "phantom" libpthread library which would
take care of keeping a map of the pthread_t <-> Linux TID mappings,
and allow to retrieve the TID when requested.

Bye,

     T.

--
Tommaso Cucinotta, Computer Engineering PhD, Researcher
ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy
Tel +39 050 882 024, Fax +39 050 882 003
http://retis.sssup.it/people/tommaso

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK and RT cgroups

Gabriel M. Beddingfield-2
In reply to this post by Dhaval Giani


On Wed, 15 Dec 2010, Dhaval Giani wrote:

>> Its not just one JACK process. Its all JACK clients, the names of
>> which are not known in advance. JACK is a server client system that
>> may involve many different applications.
>
> Are they all forked by the main jack process? How many threads are
> privileged to RT priority?

The processes are not forked by jack.  They are independent
processes that communicate with the jack server.

And it's not just JACK.  Pro audio apps using the ALSA API
also need RT priviledge to get proper performance.

-gabriel
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK and RT cgroups

Peter Nelson-4
In reply to this post by Dhaval Giani
On Wed, 2010-12-15 at 18:33 +0100, Dhaval Giani wrote:

> Now, I am not inclined
> to change that because JACK is a special case and in most cases normal
> users should not be launching rt processes and in case there is
> someone else, they can explicitly provide those powers.

Actually this affects RealtimeKit and PulseAudio as well.

Peter.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK and RT cgroups

Dhaval Giani
In reply to this post by Alex Stone
On Wed, Dec 15, 2010 at 7:19 PM, alex stone <[hidden email]> wrote:

> Dhaval,
> So as jack users (non-coders), with many of us having invested
> hundreds and possibly thousands of hours testing for our modest
> community, not to mention the most definitely thousands of hours of
> sweat and toil put in by the all too few jack/RT coders who have
> valiantly laboured most generously for like minded users in a shared
> desire to have great, professional quality, audio/midi/video tools as
> viable alternatives to proprietary locked in apps, we are being
> reduced to a single label, entitled "Linux User" to satisfy a generic
> perception of what someone, somewhere thinks is the definition of what
> we "should" be using? Regardless of the limitations this imposes,
> which is something we accuse proprietary OS's of?
>

Not really. As I mentioned, it is quite trivial to turn off all these
features. I honestly cannot believe that adding an extra line in a
configuration file will turn off users. If it is such a major issue,
asking your distro to add that line by default should not be a
problem. They should do so. Hey, if there are enough complaints,
letting us know upstream will enable us to turn off the policy. I am
aware of at least one distro which turns off the default group by
default. But unless people let us know, we really cannot do something.

> I respectfully wonder if the team that made this decision are aware of
> the number of jack/RT users that actually pass through our little
> village, or if the decisions being made are in earnest pursuit of a
> wider generic user base, are reflective of an honest misunderstanding
> of just how important jack/RT apps and infrastructure are for linux
> users who would rather enjoy the superb stability of linux as a viable
> professional system, over the angst that goes with the "others".
>

Honestly. I was completely unaware that the jack folks were facing
this issue until I saw the cgroups page. What upset me was that this
page was put up, but no attempt made to contact the developers who are
doing this work. (Not to mention inaccurate information). So I ask
this question, are jack users this special case for which the
developers should look out for, or like other users they let us know
when they are facing issues?

> I'm bewildered by the indifference to what i thought was a sizable and
> significant chunk of the linux community. It seems i misjudged the
> importance and superb performance of a jack based system, over the
> rest.
>

see above. I don't see jack as a special case. It would be very much
appreciated if you let us knew you were facing issues. Its not that we
want to make life tough for our users. But we need to know that we are
making life tough for them :-). This works for most users, yes. If it
were not, I am pretty sure we would have had tons of bug reports.

> Now it seems we have to start again, yes? Based on what seems ever
> increasing perception that all non coding linux users
> are......."generic".
>
> Dhaval, i have no wish to offend you, but it looks as if you've posted
> to us as some sort of apologetic afterthought. I appreciate you're in
> a bit of a spot with this, but i hope you appreciate this will make
> things more challenging for us, and make it even harder to encourage
> new users into our village in the linux user community, when we will
> have to walk fellow users though additional instructions to try and
> get what we already had, and what was already challenging enough to
> setup, for new initiates into the linux "way".
>
> Are we really of so little significance in the wider linux world?
>

Not really. Just a bit more noise would be great :-).

Thanks
Dhaval
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK and RT cgroups

Paul Davis
In reply to this post by Tommaso Cucinotta-2
On Wed, Dec 15, 2010 at 1:20 PM, Tommaso Cucinotta
<[hidden email]> wrote:

> Yes, but AFAICR, there's still a problem: Jack not only pushes the threads
> created by libjack to RT (for which it is easy to identify the Linux TID for
> attaching it to the group), but it also allows the application clients to
> pass
> a *pthread_t* value through the API, in order to raise its priority to
> RT. So, I guess now there's no way to recover the Linux TID from the
> pthread_t, so such a feature wouldn't work anymore.

this is correct, thanks for reminding me/us about that part of the JACK API.

it used, for example, by clients that need to do RT processing such as
FFT generation, but cannot afford to do it in the thread provided by
JACK.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK and RT cgroups

Dhaval Giani
In reply to this post by Peter Nelson-4
On Wed, Dec 15, 2010 at 7:27 PM, Peter Nelson <[hidden email]> wrote:
> On Wed, 2010-12-15 at 18:33 +0100, Dhaval Giani wrote:
>
>> Now, I am not inclined
>> to change that because JACK is a special case and in most cases normal
>> users should not be launching rt processes and in case there is
>> someone else, they can explicitly provide those powers.
>
> Actually this affects RealtimeKit and PulseAudio as well.
>

I haven't seen pulseaudio having issues. (Or at least no complaints
from Lennart)

Dhaval
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK and RT cgroups

Dhaval Giani
In reply to this post by Paul Davis
On Wed, Dec 15, 2010 at 7:31 PM, Paul Davis <[hidden email]> wrote:

> On Wed, Dec 15, 2010 at 1:20 PM, Tommaso Cucinotta
> <[hidden email]> wrote:
>
>> Yes, but AFAICR, there's still a problem: Jack not only pushes the threads
>> created by libjack to RT (for which it is easy to identify the Linux TID for
>> attaching it to the group), but it also allows the application clients to
>> pass
>> a *pthread_t* value through the API, in order to raise its priority to
>> RT. So, I guess now there's no way to recover the Linux TID from the
>> pthread_t, so such a feature wouldn't work anymore.
>

Sorry for my ignorance, but I miss how a thread is promoted to rt
priority without knowing its tid?

Dhaval
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK and RT cgroups

Paul Davis
On Wed, Dec 15, 2010 at 1:37 PM, Dhaval Giani <[hidden email]> wrote:

> Sorry for my ignorance, but I miss how a thread is promoted to rt
> priority without knowing its tid?

pthread API
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK and RT cgroups

Paul Davis
In reply to this post by Paul Davis
On Wed, Dec 15, 2010 at 1:35 PM, Tommaso Cucinotta <[hidden email]> wrote:

> I would be interested in getting more details about a specific case. Do you
> have any practical example and perhaps explain better why we need a
> different thread than the Jack-provided one, and how the additional thread
> fixes the situation ?

FFT's are very expensive. FX that rely on spectral data need them but
it will take a while to compute them. So the JACK client that does
this sort of thing will declare that it delays the signal somewhat,
and will shunt the FFT computation off into 1 or more supplementary
threads to avoid stopping the smooth flow of audio. It still wants
that data ASAP, to minimize whatever latency it adds to the signal
path.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK and RT cgroups

Tommaso Cucinotta-2
Il 15/12/2010 19:39, Paul Davis ha scritto:

> On Wed, Dec 15, 2010 at 1:35 PM, Tommaso Cucinotta<[hidden email]>  wrote:
>> I would be interested in getting more details about a specific case. Do you
>> have any practical example and perhaps explain better why we need a
>> different thread than the Jack-provided one, and how the additional thread
>> fixes the situation ?
> FFT's are very expensive. FX that rely on spectral data need them but
> it will take a while to compute them. So the JACK client that does
> this sort of thing will declare that it delays the signal somewhat,
> and will shunt the FFT computation off into 1 or more supplementary
> threads to avoid stopping the smooth flow of audio.

The piece of the puzzle I'm missing is, in case the other thread(s)
don't deliver the requested filtering operation on time, how can you
avoid an audible glitch ?

So, isn't all this FFT computing and the like needed to absolutely
terminate within the audio cycle anyway ?

 From another perspective: is such a feature perhaps much more useful on
Jack-1 without the "jack2" multiprocessing/pipelining capability ?

Thanks again,

     T.

--
Tommaso Cucinotta, Computer Engineering PhD, Researcher
ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy
Tel +39 050 882 024, Fax +39 050 882 003
http://retis.sssup.it/people/tommaso

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK and RT cgroups

Fernando Lopez-Lezcano
In reply to this post by Dhaval Giani
On 12/15/2010 10:08 AM, Dhaval Giani wrote:
> On Wed, Dec 15, 2010 at 7:03 PM, Paul Davis<[hidden email]>  wrote:
>> What was written on the page at jackaudio.org was written out of
>> ignorance about how to set up cgroups. It was written as a page for
>> JACK end users, for whom the type of instructions you listed would be
>> reason enough to simply walk away.
> Even an instruction as simple as
>
> open /etc/sysconfig/cgconfig and change the line which says
> DEFAULT_CGROUP=yes to DEFAULT_CGROUP=no ?

That is simple but it is a just a workaround (not that it claims to be
anything else).

> seriously? I see so many ubuntu workarounds which have much more
> complicated steps, and people are quite happy to follow them.

[I'm not an ubuntu user] Really? While I'm grateful when there are
"complicated workarounds" posted that fix problems (that usually should
not be there in the first place), I can hardly describe my state of mind
when I follow the sometimes complicated list of instructions as "happy" :-)

-- Fernando

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
1234