[PD] Real-time Linux; hard req. and suggestions?
claudiusmaximus at goto10.org
Fri Sep 8 06:55:36 CEST 2006
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.
More information about the Pd-list