Subject: Re: [linux-audio-dev] Re: laaga, round 2
From: by way of Anders Torger (Anders)
Date: Sun May 13 2001 - 01:03:58 EEST
On Sunday 13 May 2001 02:45, you wrote:
> On Tue, 8 May 2001, Alexander Ehlert wrote:
> >> and works remarkably well --> AES&Ardour!!! Ie. the one-thread-only
> >> approach _works_. So until other mechanisms are proven to work this
> >> well, one-threaded model is the one I'm interested in.
> >
> > If you're wondering wether a multithreaded approach works, I can offer
> > glame as an object to study. Every plugin in glame runs in his own
> > thread, even ladspa plugins. With this approach it's even possible to
> > have a
>
> Have you done testing under high system loads? I've tested various
> multithreaded approaches in ecasound, but in most cases, I've returned
> back to simpler designs.
Another example is my filter software BruteFIR
(www.ludd.luth.se/~torger/brutefir.html), but I use multiple processes and
shared memory rather than threads (synching with pipes). I chosed processes
instead of threads because it is a more portable solution (although BruteFIR
isn't very portable at the moment, mainly because it uses gigantic System V
shared memory segments). I use multiple processes mainly to improve
performance on multiprocessor machines. I have myself a 2 processor machine,
and can get twice the filter performance compared to running in a single
process. Currently, the user has to explicitly tell the program how many
processes it should run, and which filters should be in which process.
My program is not a low-delay (min ~100 ms delay) program though, so I don't
get problems with context switching/synchronisation overhead.
When talking about threads, it is worth noting that Linux implements threads
as processes, while more advanced (==complex) operating systems like Solaris
(or Windows 2000) automatically chooses between starting a new kernel thread
to hold the new thread, or run it more lightweightedly within the same kernel
thread. This way a single process can hold 1000 threads without any problems,
while a Linux program with more than 20 threads starts to behave really
poorly due to costly context switches. I cannot see why an audio application
would need 1000, or even 20 threads though. Server software for enterprise
environments may benefit from it though (a thread per client).
/Anders Torger
This archive was generated by hypermail 2b28 : Sun May 13 2001 - 01:22:27 EEST