Hello, all, We all have probably experienced some interruptions in sound when using Pd. My usual solution has been to increase the size of the audio buffer til the interruptions occur less frequently, and I've tried using -rt. I've tried hacking the kernel (the easy way--menuconfig) to enable preemptible options. Somehow, it's just not satisfying.
I've started learning a bit about alternative kernels for real-time linux, and I've got some masochistic notion to investigate Linux From Scratch. One of my friends says this is his favorite way to build a system...I have a lot to learn. I'm currently using Fedora Core 4 with the 2.4.19 kernel on a 1.6 GHz Sempron processor (could be upgraded to an Athlon64). I'm not sure which system specs are most important for getting good throughput, front side bus, memory access speed...how to balance them?
The graphical interface run by Xwindows puts more demands on the system. I admit to not knowing enough about how an OS really works, but one concern I have is that the graphical rendering can hurt audio performance. If I follow through on this idea, I'll learn more as I go.
I've been reading some articles on www.linuxdevices.com and www.realtimelinuxfoundation.org which of course raised some questions. The "hard real time" spec refers to a certain maximal time frame for execution of a block of code. For instance, with Pd, there's an audio buffer of 64 samples transferred from sound card to RAM, which I think requires a system interrupt. Then, Pd has to be scheduled to run every 64 samples as well. At 44,100 Hz this is about .7 ms. So, the vexing questions about this...Is there a lower bound (shortest time) for running a dsp cycle using Pd? What would be a large enough "hard real time" spec to run Pd successfully? Just how low can your latency go?
Any advice for choosing a kernel (my first step) is much appreciated ;)
Chuck