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