[LAD] Kontakt Spikes

Hi list, We are seeing unexpected interruptions of SCHED_RR audio processing threads, and are struggling to understand why they are happening. Does anyone have any good tips or tools to suggest to help figure out what is preempting or delaying realtime audio threads? The issues are coming up with Receptor [see (*) below for an intro] running its 2.6.24.3 CCRMA based kernel. The bug appears with Receptor in its "dual core mode", with three instances of Native Instruments' Kontakt 4 in DFD + multi-core mode. Either lots of held notes, or large patches are needed to get the spikes. With these settings there are 5 SCHED_RR threads processing audio (on a two-core system). 2 are from Receptor, and 1 from each instance of Kontakt. These Kontakt "helper threads" are released to do work as possible while the audio thread is processing. Kontakt/DFD is using mmap to bring its files into memory. This is done in a lower priority "DFD thread", and the mapped memory is used by the r/t audio threads. DFD is important because the problems don't happen without it. And the high SCHED_RR thread count is important, because the problems also don't happen if we reduce the count. When the spike happens there are no: * wine bottlenecks * system calls * threads blocking on each other * page faults during audio processing There do appear to be "involuntary context switches" (as reported by getrusage) when the spikes happen. This makes it seem like the scheduler is interrupting our threads. But how do you figure out why that is happening? There aren't many threads in the system with higher priority. All of the 5 processing threads are SCHED_RR/76. The higher priority threads in the system are: * migration/0 - FIFO/99 * migration/1 - FIFO/99 * watchdog/0 - FIFO/99 * watchdog/1 - FIFO/99 * posix_cpu_timer (x2) - FIFO/99 * IRQ8 (rtc) - FIFO/99 * IRQ20 (our audio card) - FIFO 77 Could other kernel activity interrupt the audio threads? Are there issues with memory mapping, that can block other unrelated threads? Are there just too danged many SCHED_RR threads fighting for two cores? Anyone have any suggestions for how to trace the scheduler, and thread or process interruptions? Apologies for the lengthy post, but this is a tricky subject. Thanks for any tips or insights, Michael Ost Muse Research & Development (*) Receptor (http://www.museresearch.com/products/receptor.php) is a standalone hardware VST plugin player. It runs Windows VSTs using Linux and Wine in a proprietary host program. We have patched Wine (ftp://anonymous+museresearch.com@ftp.museresearch.com/rpms/1.8/wine-1.1.7-muse16.fc8.src.rpm) to make it work better with VSTs in our environment.