Subject: Re: [linux-audio-dev] Why? call back API and other thoughts...
From: Roger Larsson (roger.larsson_AT_skelleftea.mail.telia.com)
Date: Fri Feb 28 2003 - 16:36:56 EET
On Friday 28 February 2003 14:49, Fons Adriaensen wrote:
> Roger Larsson writes:
> > - - -
> > 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.
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.
>
> 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
This archive was generated by hypermail 2b28 : Fri Feb 28 2003 - 16:40:47 EET