28 Feb
2003
28 Feb
'03
10:49 a.m.
On Friday 28 February 2003 14:49, Fons Adriaensen wrote:
Roger Larsson writes:
But the point is that you get the push(!) from the wrong direction.
It is not important to work ahead it is important not to miss the deadline.
- - -
In a pure push model each processing step reads data from
one file/pipe/device, processes it, pushes it to a file/pipe/device
You get:
* lots of threads/processes that are not optimally synchronized.
Any thread is runnable when there are input available until the
output is full.
But that is not the important case, concider the case when the last
processing steps output is almost empty (if it gets empty you will hear
a click). How to prioritize it higher than all other threads? Should it
always be higher? Suppose it is a mixer that has several inputs...
Could be done by a super server that sets priorities depending
on position in the line? This is not easy...
There is no need to prioritize it. The possible bad synchronisation in
a 'push API' system arises from the fact that threads that do not need
any RT input (e.g. an oscillator) are essentially free running and are
allowed to 'work ahead', thereby stealing CPU time from the others.
This can easily be avoided by making these 'free-running' threads wait
on an event that has the right frequency, e.g. a counting semaphore
that is incremented by the output module each time a block is processed.
This way you can eleminate all buffering between the threads, and
you get a system that is as deterministic as e.g. JACK.
Easily avoided? By adding semaphores and more? The point is that you can
not keep it as simple as pipe in pipe out. By adding semaphores the push
model is already more complex that the call back. And all problems are not
solved yet...
Suppose you have four outputs 1, 2, 3, 4 where 1 and 2 is used by pluggin A
and 2, 3 and 4 is used by pluggin B. Then there have to be one counter per
pluggin and those pluggins that generates the outputs has to know of and
update both... or?
- - - [jack]
The same effect can be had by using ITC mechanisms that allow you
to specify more complex conditions that a thread can wait for. The
result is a 'push-API' system that is completely deterministic and
as efficient as JACK. This is no imagination, I am using such a system
for telecom DSP applications. ITC is based on pthread condition variables.
OK, but you did not mention simple - is it also as simple as JACK?
/RogerL
--
Roger Larsson
Skellefteå
Sweden