Re: [Protux-devel] Multiple threads

[Remon Sijrier]

> Surely this is a good idea. Mixer is doing such function right now, by
> starting independent
> threads .

Hmm, do you have any idea where to put this class, (mustux or protux) and
well, I do not have an idea yet how to implement it.
If you have one, please tell me, it is very important that the
peakBuildThreads are serialized.
Well, I have a litle bit of an idea:

Add a ThreadControl class to mustux or protux, and make it an attribute of
Song or Project?. ThreadControl starts a thread  for each type of thread
(maybe not necassary) and makes use of QSemaphore to control the amount of
simultaniously running threads. Don't know if this is possible, but:
ThreadControl.cc
<snip>
Thread peakBuildThreadControl = new PeakBuildControlThread;

PeakBuildControlThread::add_thread()
{
if(ThreadType == peakBuildThread)
    PeakBuildControlThread->add(PeakBuildTread);
<snip>
}
and in the logic of the peakBuildThreadControl:
<snip>
    while(numberOfThreadInQeue != 0)
        'some stuff that's starting the remaining threads after a thread
ends execution'
<snip>

> But each thread is related to a armed BUS no armed track. So if you have
> assigned 4 armed tracks
> from 4 different buses, you will get for independent threads.
I didn't meant threads related to recording/playing, as these threads are
private to mixer/MADM. Thats right, isn't it?


> The priority matter is not important, since protux is supposed in RTC mode
> , where all threads (and child threads)
> have the maximum priority from the kernel, reducing the latency problem
> and going sync'ed through recording process.

(See above), but the peakBuildingProcces now is only a CPU related task,
no more hard disk involved. For large recordings, it (still) will take a
certain amount of time to proces the peakfiles, but for that time, you'r
cpu is almost dying, and even with a preemptive kernel, the GUI isn't
responding for the time the cpu is building the peakfiles. Due the fact
that peakbuildproces is running in threads, this behaviour is reduced a
litle, but as peakfiles are less important then GUI interactivity I wanted
to run those threads with a lower priority.

Another reason:
Applying a destructive filter. By doing this in a thread, and give a lower
priority, you still can use protux for editing purposes, or whatever you
want to do with your computer while you have to wait until the filter
proces is done. Ehm, very bad English I hope you got the point :-)


Remon.

P.S. I now really am offline until monday,