On Wed, Dec 02, 2009 at 11:16:30AM +0100, Stéphane Letz wrote: See my other post - the easiest way would be to make the main thread wait for the others. It could but I don't think it would simplify matters much. Supporting many parellel period sizes *would* complicate Jack a lot. Paul Davis: 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 ?

On Wed, Dec 02, 2009 at 08:19:06AM -0500, Paul Davis wrote: In the general case this would be correct, SCHED_FIFO does not in any way ensure that threads get a 'fair share of time'. But this is not the general case. In cases such as the one discussed, the threads are triggered at a divisor of Jack's period rate. Each time they get a quantum of work, perform it, and wait for the next trigger. They do not try to run for as long as they can. The threads do not compete on CPU time: the assumption is always that there is enough CPU power to perform all the work. If this is not the case the whole thing fails anyway. The 'competition' is on the order in which they are allowed to run, and for that priority is the only criterion. The objective of the priority scheme is to allow all threads to meet their deadline, not to give them equal CPU shares. They don't need equal CPU shares anyway, in most cases the bulk of the work is done by the lowest priority ones. An example should make this clear. Assuming the period size is 256, running the 'Great Hall' reverb in jconvolver, configured for a minimum partition size of 256 (no processing delay) will result in the following threads: (you can use -v to see this) prio = 0, offs = 0, parsize = 256, npar = 3 prio = -1, offs = 768, parsize = 512, npar = 6 prio = -3, offs = 3840, parsize = 2048, npar = 6 prio = -5, offs = 16128, parsize = 8192, npar = 13 The first one is Jack's process thread, this will do the work for 3 partitions of size 256. The second one will do 6 partitions of size 512, it will be triggered every two periods. The next one runs every 8 Jack periods, the last one every 32. The last three are required to have completed their work when the next trigger arrives. Their output is actually only required later, 3 periods after the start for the size 512, 15 periods for the size 2048, and 31 for the last. This gives the whole system some robustness it would not have if everything was planned 'just in time'. Note that the extra margin is small for small partition sizes and quite big for the larger ones. Now if the same reverb is configured to use a minumum period size of 4096 (because the user can tolerate the delay and wants less CPU load) this would look different: prio = -4, offs = 0, parsize = 4096, npar = 2 prio = -5, offs = 8192, parsize = 8192, npar = 14 As you can see the priorities match the partition size. In this case no work is done in Jack's thread. Now assume that I would use the scheme of version 1.0.0. Then the priorities would be -1 512 -2 2048 -3 8192 and -1 4096 -2 8192 respectively. This would mean that the size 4096 thread of the second instance would have the same priority as the size 512 thread of the first. The time required for the size 4096 calculations could easily be longer than the period of of the size 256 thread. This would result in the size 256 thread being late every time it has to wait for the other to complete, which could happen every 16 periods. Matching priorities to period size removes this problem, and ensure that the most urgent work will always be done first. Ciao, -- FA Wie der Mond heute Nacht aussieht ! Ist es nicht ein seltsames Bild ?

On Wed, Dec 02, 2009 at 12:32:12PM +0100, Arnold Krille wrote: It's not the only solution but surely the easiest. The semaphores that would be required are already in place (they are used for checking readyness now). The complicated part could be switching between the two regimes. I suspect this can't be done 'instantly', it could require a multi-step process spread over a series of periods. Maybe I'm overestimating the complexity, but I try to step gently as organising the cooperation of these threads was not a simple task. The code looks simple, but that's the result of my usual irresistable urge to simplify every algorithm down to its essentials. I've not really tried to solve this ATM, but will do if some free time drops from the (currently) blue Italian sky. Ciao, -- FA Wie der Mond heute Nacht aussieht ! Ist es nicht ein seltsames Bild ?

On Sat, Dec 05, 2009 at 05:09:06PM +0100, torbenh wrote: Yes. The version that was released is based on code that is half a year or so old. I wanted it out because it fixes at least one bug, and also provides some features I may need. Meanwhile things have evolved but the new version is by no means ready for release. Thanks, seems you understand my cryptic code :-) Your solution avoids the 'transition' problem by always counting, but doing this requires the condvar as you can't decrement a sem_t atomically without waiting for it. Using a condvar with its mutex is something I wanted to avoid at all cost - it would just lead to the code not being considered realtime safe, even if the risk in practice is very small. Meanwhile I *do* have a solution using just sem_t. Switching the thread priorities is not necessary. While freewheeling the worker threads can remain realtime, and for non-realtime use a Convproc can be configured to run entirely in the caller's thread. Changes in the new version are to solve another problem: The largest partition size is 8192, that means a thread that is triggered at a frequency of around 6 Hz and that could take significant time (up to 160 ms) to complete. This has a clear impact on e.g. GUI responsiveness. To avoid this, the work done in that thread has to be split up in e.g. four parts, with in between some pause to allow others to run. The problem is where to put the pauses, condidering that in general a configuration could consist of an arbitrary sparse 3-D matrix. Ciao, -- FA