Re: [LAD] [LAU] Update of jconv

On Sat, Dec 05, 2009 at 05:09:06PM +0100, torbenh wrote:

> hmm... but thats the trigger semaphore.
> and the worker thread blocks on it. so the process thread cant block on
> it. or are you talking about some non released code ?

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.

> i added a semaphore like construct built with pthread_cond
> the RT thread only decrements the counter and in sync mode
> wait for the counter to be zero.
>
> this allows instant switching.
>
> using more than 1 line for syncying clutters the code though, but as
> this kind of stuff is a matter of taste, i leave that up to you to
> move it into a separate method or class.
>
> patch is attached

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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev