[linux-audio-dev] audioengine/laaga snapshot and some performance data

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: [linux-audio-dev] audioengine/laaga snapshot and some performance data
From: Paul Davis (pbd_AT_Op.Net)
Date: Sat Jun 16 2001 - 07:06:19 EEST


as usual, http://www.op.net/~pbd/audioengine-0.0.1.tar.gz

the big change is the use of named pipes to link the components into a
processing graph. against expectations, this turns out to be faster
than using signals, probably because of the overhead of a
posix-compliant sigwait() implementation. i didn't bother to try a
"raw" signal implementation using sigblock/sigpending/sigsuspend,
since it would violate the pthreads API specification.

the basic engine process() call, which would be executed when a
"driver" tells the engine that its ready, takes 2-5usec with no
clients.

i have now run 4 "minimal" out-of-process clients. the total cost to
get out and back to this linked series of o-o-p clients is about
150usecs. this includes their run time. interestingly, with just 2
o-o-p clients, its only about 35usecs. it jumps dramatically when the
3rd client starts running, but then stays stable again. i've gone to 7
clients and the time doesn't increase much over the 150-200usec
range. this is on a PII-450. you can expect to see this drop quite
noticeably as the clock speed of the processor increases, as long as
the client memory footprint stays small.

of course, since this is Unix, the clients are all using the same
instruction data, so this is not a very realistic test.

the server seems stable in the face of client exiting, be it through
calling audioengine_close(), or death due to a signal. we detect CPU
runaways and other timeouts reliably, and we remove the clients that
caused them from the graph.

i have a little work to do cleaning up some things that i don't like,
adding a couple of things (e.g. port creation notification to 3rd
parties) and then quite a bit more to add support for in-process
clients. after that, this is very close to the point where i consider
it a working prototype of a LAAGA API and a working implementation of
the engine along with a simple example client. my first 0.1.0 release
will include a "driver" for ALSA 0.9.X, which is dynamically loaded by
the engine.

i have an outstanding problem right now: its hard to dynamically
increase the total number of output ports in the system. the shm
segments that we use for port buffers need to be mapped into each
client's address space at the same location, and this can be hard to
do, i think. any comments or ideas on this are very, very welcome.

BTW, i note with some irony that the system i've implemented is
actually very close to the original goals of MAIA :)

--p

----------------------------------------------------------------------

DONE:
    convert to use of named pipes to drive the graph
    more testing
    AF_UNIX domain for server connections
    checking data flow
    reimplementing support for SCHED_FIFO etc.
    
TO DO:
    port creation/deletion notification
    dynamic reset of engine "buffer size" (e.g. h/w interrupt interval)
    driver side

TO THINK ABOUT:

    multiple port buffer shm segments (i.e. dynamically
         increase the total number of ports in the system)


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sat Jun 16 2001 - 07:02:16 EEST