Subject: Re: [ecasound] CVS changes; old code removed, mmaping files
From: Kai Vehmanen (k@eca.cx)
Date: Mon Oct 23 2000 - 22:42:02 EEST
On Mon, 23 Oct 2000, Jeremy Hall wrote:
>> 2. Double-buffered mode, -z:db. I have plans ready for a new buffering
>> system, which will replace the old one. Unlike the old -z:db, the new
> What's it going to do when it gets going on a machine that doesn't support
> mthreaded?
The new double-buffering code? Well, it'll run like any other multiprocess
application on a uniprocessor machine. If you specifically meant threads,
they must be supported. It's impossible to compile ecasound on a machine
without proper POSIX threads implementation.
Threads are needed even though the "-m:mthreaded" mixmode has been dropped
from the current CVS-tree. Ecasound uses a dedicated thread for the
iactive-mode, MIDI i/o, and in the future, for the new -z:db code. I guess
it could be possible to make a "no-threads" compile option, but you only
could run ecasound in passive mode, without MIDI and without -z:db.
As for how threads behave in different systems (multiprocessor,
uniprocessor), they are just like normal processes with shared mem. It's
also worth noting that use of threads is not aimed for SMP-systems, but to
separate different subsystems i/o-wise.
In the end, it all comes down to latencies. Ecasound is a big i/o
processor that reads from various sources (files, soundcards, pipes,
MIDI-devices, keyboard), processes and writes to various targets. The
problem here is that different i/o object types have different
charateristics. Soundcard i/o requires that ecasound _must_ do read/write
at a certain rate. Even one missed read/write operation, and you get a
overrun/underrun (you hear a pop in the resulting audio stream). Also,
time it takes to read/write from/to a soundcard is fairly deterministic.
Disk i/o differs in this respect. Advanced operating systems like Linux
have a complex buffer cache system between the applications and the
lowlevel disk drivers. This is good for disk i/o performance, but has
unfortunate side-effects for realtime apps like ecasound. Unlike with
soundcards, the time it takes to do a single read/write operation from/to
disk varies. Sometimes it's fast (close to physical harddrive speed), but
sometimes it may take longer (kernel decides to flush some caches).
Now if soundcard and disk i/o are handled in the same i/o engine (one
process/thread; the normal situation in ecasound), variances in disk i/o
latency can potentially cause missed deadlines (dropouts) in soundcard
i/o. This is the core of the problem.
The idea behind doublebuffering is to always read-ahead and write-behind
when doing disk i/o. In the optimal case, variances in disk i/o latency
will only affect how these buffering areas are filled. This system won't
help, if your harddrives just aren't fast enough, but it will help to
handle variances in disk i/o latency.
Another, completely separate (!), issue is process scheduling latencies.
This is what most people talk about when talking about
lowlatency/real-time kernel features. Basicly here latency means the time
it takes for a process to get kernel "focus" after losing it. In a
multitasking environment, cpu time has to be divided; first runs app A,
then B, C, and then back to A. With a lowlatency kernel, it's guaranteed
that the A->B->C->A cycle is short. For instance if app B is accessing a
floppy (try this in Windows), it shouldn't get any more cpu time than
normally, ie. app A can rely on re-getting the focus in few msecs.
So the point here was that scheduling latency is not the same as disk i/o
latency. Of course, both are important to ecasound (and all multimeadia
streaming apps).
-- . http://www.eca.cx ... [ audio software for linux ] /\ . . http://www.eca.cx/aivastus ... [ aivastus net radio ] /\ . . http://www.eca.cx/sculpscape [ my armchair-tunes mp3/ra/wav ]-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.
This archive was generated by hypermail 2b28 : Mon Oct 23 2000 - 23:04:29 EEST