Subject: [ecasound] large ecasound changes in progess
From: Kai Vehmanen (kai.vehmanen_AT_wakkanet.fi)
Date: Thu Feb 28 2002 - 22:43:58 EET
As a small preannouncement, I've spent the last few days (and nights
unfortunately) reworking how ecasound's core classes interact. The
ultimate goal is to make it possible for ecasound's engine to become part
of a synchronous system like JACK. Most of this work relates to edi-22,
"Engine iteration from outside sources".
The good news is that all the big changes are now done. Considering how
much code I've touched, suprisingly few things broke. ;) Communication
with jackd is now more efficient, but there are still some cornercases
where performance is not good enough.
Some of the performance bottlenecks really seem strange. For instance with
the current ecasound version I can stream a wav-file to jackd without
xruns with a buffersize of 256 frames and jackd running with options
"--asio -p 256 -n 2", and running _without_ root priviledges and
sched_fifo scheduling. This is pretty awesome!
But on the other hand, when ecasound and jackd are run as root with
sched_fifo enabled, I always get a few 10-20msec latency spikes in the
client side code. Because of this, operation with smaller buffersizes than
1024 does not work at all if run as root. And I don't seem to be able to
pinpoint what actually goes wrong. I've placed rdtscll and gettimeofday()
counters to almost every imaginable place in the code path and to no
avail. Oh well, I can always start tracing kernel scheduling...;)
There are still some big regressions in the current code, so I won't
commit it to CVS just yet. The biggest ones are:
- multitrack recording doesn't work; I'll need to rewrite
the sync logic
- prefilling rt-objects doesn't work; JACK doesn't need
this but other rt-object types do
-- http://www.eca.cx Audio software for Linux!-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request_AT_wakkanet.fi>.
This archive was generated by hypermail 2b28 : Thu Feb 28 2002 - 22:35:14 EET