On Wed, Dec 02, 2009 at 11:16:30AM +0100, Stéphane Letz wrote: > So does this mean than going into freewheeling should be > handled in a special way: like dropping RT mode for > additional worker threads and so on (then when freewheeling > stops, you would have to setup RT mode again...) See my other post - the easiest way would be to make the main thread wait for the others. > We could even imagine that JACK could provide some support > for this kind of requirement : allowing to define additional > worker threads, automatically handling priority change when > freewheeling on/off.... It could but I don't think it would simplify matters much. Supporting many parellel period sizes *would* complicate Jack a lot. Paul Davis: > i doubt if applications with such architectures want JACK > itself to try to micromanage this level of detail. they > already have to make their own decisions about thread > priorities. These priorities maybe need some discussion. The relative period sizes used by zita-convolver are either 1:2:8:32 or 1:4:16:64. The first step is either 2 or 4, the others are always 4, and the choice of the first step is made to make the longest one (if used) always 8192. In 1.0.0 each step would decrease the priority by one relative to Jack's thread. In 2.0.0 this is different: each doubling of the period will decrease the priority by one. This change ensures that threads using the same period will have the same priority, even if they are not in the same client. This is absolutely necessary in order to make two or more such clients work together smoothly and have 'fair' scheduling. This should become some sort of 'standard' if more apps start using such schemes. Threads doing disk-IO probably don't fall in this scheme, I suspect they always use much larger block sizes, have plenty of buffering and can run SCHED_OTHER. Ciao, -- FA Wie der Mond heute Nacht aussieht ! Ist es nicht ein seltsames Bild ? _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
