On 02/14/2011 03:32 PM, Jeremy Jongepier wrote: * puredata aka pd when run with `pd -rt` as well; * supercollider's "sclang" can do so * qsynth/fluidsynth (depending on config and backends: midi.realtime-prio' and 'audio.realtime-prio') I don't know about rosegarden, qtractor, hydrogen, seq24, ams, csound, chuck, aeolus, bristol, ecasound, snd-rt, a2jmidid, lmms, midish, qmidinet, gstreamer, CLAM, etc, etc. I suppose all ALSA-midi/sequencer instruments that can be played, recorded or used live should set up RT scheduling; not all of them do that [yet]. Same goes for non-JACK ALSA or OSS audio apps. Many authors/maintainers of audio software are subscribed to LAD. If it really boils down to collecting a white-list: call there. Some closed source apps: eg skype or baudline may try to setup RT scheduling?! and there's A/V apps and video-players, too. `ps -Leo rtprio,ni,pri,comm` will tell. I need to say that I'm not a friend of black/white listing. What are the alternatives? ciao, robin

Bristol runs the audio and midi threads with RT prio, these can be overridden with command line options to allow for inheritance. Realtime MIDI messages (note on/off for example) are actually fielded in the audio thread anyway, the param changes are taken in the MIDI thread. Nick.

On 02/14/2011 06:13 PM, R. Mattes wrote: qsynth -o midi.realtime-prio=60 Best, Jeremy

On 02/14/2011 08:29 PM, R. Mattes wrote: http://qsynth.sourceforge.net/qsynth-index.html#Configuration -- Robin Gareus web: http://gareus.org/ mail: robin(a)gareus.org lab: http://citu.fr/ chat: xmpp:rgareus@ik.nu Public Key at http://pgp.mit.edu/ http://gareus.org/public.asc Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42

On Mon, 14 Feb 2011 23:42:22 +0100, Robin Gareus wrote Are you saying that I can put fluidsynth settings in this file? What's the syntax? Under what group would I put stuff like midi.realtime-prio=60? TIA RalfD

On 02/14/2011 03:15 PM, Robin Gareus wrote: yes. what can be done is to bind those to certain cpu cores, don't know if this can help reducing latency, tho. Are these processes parent of jack or do they just connect to it ? If these are only connected, how can i get a list of all pids in the graph ? do you have me same simple command i just can run that causes non trivial load on jackd and it's childs to test ? ok. of course. PA is for desktop usage, not pro audio :-) I have chosen 45% rt because on a normal desktop the user does not expect that some rt task started for whatever reason will eat up all cpu power. But of course, for pro audio this is ok. Switching configurations in ulatencyd is just a two clicks and a password away. You can change the default configuration, too. I simply think that "one configuration fits all" does not work. You can make a configuration that does not suck, but will be far from perfect. I goal is perfection for different workloads :-) For a typical desktop system, it's pretty close. I don't restrict to idle, at least thats not the intention. The only thing the desktop config does restrict is the RT amount, because I don't think that more then 45% cpu is a normal workload on RT tasks on a desktop. each group has a cpu.shares value and a rt_runtime_us (along with other values). cgroup_a cpu.shares 10: task 1 task 2 cgroup_b cpu.shares 5: task 3 task 4 imaging all 4 tasks want 100% cpu time, then in this setting task 1 & 2 get 66% of the cpu time and task 3 & 4 get 33%. if you put all in one group: very task gets the same cpu time. shares that are not used will always be given to other slots, so there is no disadvantage in giving a group a higher share. finding good groups of processes is of course not a easy task to get right. the current grouping works very well for desktops. i ment of course the complete graph. If you get like 4 cores, you move all processes to 1 core and use the 3 remaining cores to do audio only. what about a configuration like this: - rt_audio: cpu.shares 3000 rt: 99% - desktop ui: cpu.shares 500 rt: 0 - audio ui: cpu.shares 2000 rt: 0 - the rest: cpu.shares 100 rt: 0 ? kind regards daniel

On 02/14/2011 04:33 PM, Daniel Poelzleithner wrote: JACK sets up these threads, but they reside in the context of the client app's process ID - which call jack_client_new(). there was a recent discussion on jack-devel: http://comments.gmane.org/gmane.comp.audio.jackit/23110 also check the jack-devel archive starting December 15 2010: http://comments.gmane.org/gmane.comp.audio.jackit/22928 and http://trac.jackaudio.org/wiki/Cgroups might be helpful. The easiest is to start jackd and jamin. The latter sucks ~15%-50% CPU alone (depending on your CPU freq). Tou can also start a few instances of jamin. http://rg42.org/gitweb/?p=jackfreqd.git;a=blob_plain;f=tools/busyjack.c is a small tool that allows to generate JACK DSP and CPU load. Start a few of them (depending on how many cores you have). hehe, my desktop - for example - also runs on JACK (+ alsa-plug for flash etc). aww right /me slaps head. Thanks for the explanation. Let me comment on those later or tomorrow, I've got a train to catch. maybe s.o. else (jack-devs: wink wink nudge nudge) can jump in.. looks like a good starting point to me. Cheers! robin

On 02/14/2011 07:40 PM, torbenh wrote: It was just an idea to help reducing latency by preventing rt threads to move to other processors. currently the processes could still be interrupted by in irq i think, masking the irq handler off from those would change that. i got it running with ulatencyd, but i will need to change some things in the core to make it better and safer first. not for me :-) i want perfect latency on my desktop gui, more cpu to the active program I'm using, protection against amok processes, swap of death and io bottleneck situations. whatever i do, how crazy it may be like a make -j 40 on the linux kernel, the desktop needs to feel fast: and that it does :-) cgrulesengd and ulatencyd clash and won't work together. The config format of libcgroup doesn't make sense for ulatencyd as it works completely different. In fact, i even tried libcgroup for the cgroup low level stuff and dropped it as it was just to buggy, bloaty and hard to use. What i will do soon is to write a plugin that parses easy to use config files, so processes can be flagged easier. kind regards daniel

On 02/15/2011 11:31 AM, torbenh wrote: I changed a lot of rt detection yesterday. Now a process that ever got rt in one thread is moved to a rt group with lots of rt power, and will never leave it again. This should prevent that a process sets and releases rt more often and would leave the group and could rt starve. I know thats a problem, one thing is that i refresh in a interval all processes and threads. The next thing is to add a whitelist for rt programs. So, the worst thing that could happen is that a process spawning a rt thread will live one interval with very little rt time. Yes. I saw this problem, too. I now observe all kernel processes, not just the process leader. Many programs seem to set the rt prio only on threads and this caused problems. The rules are traveled top to bottom, the first rule that matches will be used. If it contains children, those are tested. So, the new rt group is very top, so it will never get moved into another group as long as the check function matches. I usually tend to just fix problems and attach a bugfix to the ticket, but when obvious bugs don't get fixed, my passions for a project falls quite deep :-) kind regards Daniel

On 02/15/2011 05:16 PM, torbenh wrote: i guess you mean the delay queue here. thats a delay before a process is even looked at, because you have so many short living processes, that running the rules on them is just useless. It makes of course some rules harder to implement, like cating the parent of a process as it may already be parent of root when the delay hits... If I implement whitelists, I will hook it into this loop so it will circumvent it. One problem is, that the rt_runtime_us is not hierarchical as I understood the problem. So when i have group a with limit 10 and two childs with each limit 10, they both could result in 20 spent and are not capped by the 10 limit of the parent, right ? I'm thinking about some workarounds. - Giving the groups a larger rt slot that is substracted from the rt group. - Writing a simple kernel module that would move rt threads to a given group. I saw you on the kernel mailinglist before and you seem to have more insights then I have. Is this possible ? - Writing a autowhitelist plugin that remembers tasks that got rt prio before and moves them accordingly. Sure. Sorry to sound like a noob, i never used rt actively before :-) I'm 100% pro unified whitelist :-) As long as the format does not contain unnecessary specifics for certain implementations and is not that heavy to parse :-) shall we start a wiki page, maybe on freedesktop to drop ideas and requirements ? yes, that would be great. I suggested some generic interface on the freedesktop mailinglist as i think that a generic interface between userspace and a system optimizer is required. Unfortunately there was zero response... There are a lot of potential there for all system types. kind regards Daniel