17 Jun
2004
17 Jun
'04
11:23 a.m.
[Joshua Haberman]
yes, it's at quitte.de. probably a beast to build, and with
mismatching documentation, but i'll be glad to help if you want to see
it in action. although it works kindof OK, the disk interaction code
is scheduled for an overhaul sometime soon; i guess that the ardour
code is a much better model.
the fifo code is nothing special i guess, your usual ringbuffer. the
only assumption it makes is that int and void * data type access is
atomic, iirc.
works just
like the scheme i am using, with the exception that the
graph management code is always run in the audio thread. lots of
lock-free fifos for everything and their cousin, but glitch-free
performance with absolutely no locks in the realtime code path is
worth the effort.
Is this code publicly available? What algorithms are you using for
your lock-free fifos? One thing I am still looking to learn more about is how
to adjust
thread priorities and such to make sure that your threads are run often
enough (especially the disk thread), and how to decide how big your
disk buffers need to be.
my impression is that the only threads that need heightened priority
are audio (of course) and the MIDI I and O threads. i prefer giving
the audio thread the higher priority so the DSP parts can benefit from
caching the most, and give more reliable CPU usage figures. in
consequence, with a 64 frames audio block size MIDI can suffer at most
1.3 ms jitter at 44.1 kHz.
everybody else (disk read/write mainly) runs on whatever CPU capacity
these leave over. of course if you run a fat GUI you may want to make
further adjustments, but with sufficient buffering you usually won't
need to.
tim