[PD] Real-time Linux; hard req. and suggestions?

[Claude Heiland-Allen]

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.


Claude
-- 
http://claudiusmaximus.goto10.org