[PD] comport and servos

[Martin Peach]

Hans-Christoph Steiner wrote:
>
> Sounds like a crazy hack, but fun stuff for sure.   Maybe this will 
> give some insight to serial port jitter in general when using 
> [comport].  I measured 0.5ms to 22 ms for roundtrip latency on the 
> serial port, with an average of around 12ms.  So I guess that 
> translates to 0.25ms to 11 ms with an average of 6ms for just sending 
> or receiving.
>
> But that is some serious jitter.  I am wondering how much is caused by 
> the hardware and/or OS buffering and how much is caused by Pd and the 
> [comport] object.  It would be nice to reduce the jitter caused by 
> [comport] as much as possible.
>
I got the same or worse jitter on WinXP at 2GHz as on linux at 200MHz. I 
don't think [comport] causes any jitter, it's all in pd's scheduling. 
(MIDI is jittery too at the same level at least when triggered by metro, 
but I can't hear it listening to an external synthesizer). All that 
happens inside [comport] is the calls to the OS to do things with the 
serial port. These may be queued by the OS but probably not for 
milliseconds. I suppose I should try writing a dedicated c program to 
periodically write to the serial port and check the jitter there.
Possibly some sort of periodic metrocomport object could run in its own 
thread and send data at a frequency determined by one of its inlets...
As far as hypothetical [comport~] or [parapin~] objects go, I don't see 
how to get finer timing than the audio block size in pd with a dsp 
object, since it's the sound hardware that handles the timing there, 
with no feedback available (i.e. which sample is at the DAC right now). 
Is it possible?

Martin