Subject: [ecasound] Re: laaga, round 2 (fwd)
From: Kai Vehmanen (firstname.lastname@example.org)
Date: Sun May 13 2001 - 03:47:22 EEST
Here's a some info about ecasound&threads
---------- Forwarded message ----------
Date: Sun, 13 May 2001 03:45:58 +0300 (EEST)
From: Kai Vehmanen <email@example.com>
Subject: Re: laaga, round 2
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.
One of these experiments was ecasound's old disk i/o subsystem. It had a
separate thread for all audio file objects. Now I wasn't expecting a major
performance boost, it just seemed like a elegant design. But I also wasn't
expecting the overall performance to decrease that resulted. By replacing
the multiple threads with a single disk i/o thread handling all inputs and
outputs turned out to work much better.
Another attempt at taking advantage of multithreading was ecasound's
m-threaded mixmode. It simple broke the dsp-processing chain into multiple
parallel parts. Now here multithreading really resulted in much better
results, just as long as processing was cpu intensive (= lots of effects).
But in both above cases, the real problem was robustness. When you started
doing heavy disk i/o, delays propagated to the threads and sooner or later
some thread missed its deadline and the whole system choked. With one
thread, meeting the deadlines is just easier.
The current ecasound (2.0.0) still uses threads, but much more sparingly
than before. In a normal setup, you have four threads running:
1) engine thread (_highest_ priority)
2) MIDI-thread (high priority - running if MIDI used)
3) disk i/o thread (high priority - ... if -z:db specified)
4) ui-thread (low priority - ... if a frontend is used)
... one benefit of this simple approach is that it is relatively easy to
identify the performance bottlenecks. But it's also true that this setup
is not optimal for cpu-intensive tasks like complex dsp-networks. So this
is clearly a compromise. But for multitrack mixing and recording, the
first priority really is dropout-free operation.
-- http://www.eca.cx Audio software for Linux!
-- To unsubscribe send message 'unsubscribe' in the body of the message to <firstname.lastname@example.org>.
This archive was generated by hypermail 2b28 : Sun May 13 2001 - 00:14:24 EEST