Charles Henry wrote:
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?
First step would be to split Pd into a "hard real time" DSP thread and a "non real time" Message Processing thread, because message processing does not have an upper bound in processing time (while once a DSP chain is compiled, it generally takes the same amount of time to execute each block - the lower bound would be with something like [adc~]--[dac~] but it's the upper bound that's important).
For example, "bang"--[until] - if you run this in a "hard real time" thread, behaviour is "undefined", possibly as bad as a complete system freeze, because the software has acted outside its *guarantee* to the OS as to how it will behave. (I think my understanding of "hard real time" is correct: "program X guarantees operation Y will take at most Z time", moreover "if operation Y takes more than Z time then Undefined Bad Things Happen").
Just how low can your latency go?
I don't know enough about sound card architecture to answer.