Dennis Lee Bieber a écrit : > On Sun, 1 Oct 2006 22:28:10 +0200, "Oeyvind Brandtsegg" > <[EMAIL PROTECTED]> declaimed the following in comp.lang.python: > >> Also, I wonder what method I should be using to get a precise timing >> in my automation thread (acting as a sequencer). >> > Use a real-time OS (which neither M$ Windows nor Linux/UNIX claim to > be). > > All non-deterministic, multi-tasking, OS's (like Windows, Linux, > Solaris, AmigaOS) only guarantee that, for example, a sleep() call will > not return /before/ the time specified. There is no specification for > how much time /over/ the duration actually takes place. > > And setting the task priority into the Windows "real-time" category > is not sufficient -- I had an application that had to put out data on > six pins of the parallel port (acting as three discrete RS-422 style > balanced signals) in time with a (1KHz, as I recall) clock signal coming > in on another pin of the parallel port. The data was still getting > glitches every ~256 clocks as the OS did something in the background. > (the application was written in VC++6, and even disabled the GUI during > the data output operation. >
+++ realtime OSes != high level priority threads And for a sound production using a sequencer, it looks like to need real realtime. And dont use Python threads for realtime multithreading, even on a realtime OS (because of the GIL - Global Interpreter Lock). May use Python for some -non realtime- parts, but I would not use any scripting language (not specific to Python) for real-time work (prefer C, ADA, maybe Java with ad-hoc extensions). You may go to Python by writing a Python C extension module (doing realtime work on its own - but never relying on python GIL in critical times), communicating with normal python scripts (shared memory... things which dont need the GIL if possible). A+ Laurent. -- http://mail.python.org/mailman/listinfo/python-list
