[Joshua Haberman] >> 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?
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. >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