python threading and timing

[Oeyvind Brandtsegg]

hello

I'm writing a Python application for live music performance/improivsation,
using csound as the synthesis engine, and Python for compositional
algorithms, GUI and control.

I creating several threads:
one for GUI
one for csound,
one for a timed queue (timed automation events),
one for communication with a tcp based sensor interface.

My threads do not share data,
I use threads merely to enable several processes to run in paralell.
I think I do not need to use locks to control threads in this case,
but I'm not sure (?)

Also, I wonder what method I should be using to get a precise timing
in my automation thread (acting as a sequencer).

I've attached two simple examples of different ways I could implement threads.
The only task in these examples is to generate timed counters, but the
general procedure would be the same for more complex timed tasks.
One example uses time.sleep() to release a thread's interpreter lock,
and at the same time provide the time interval until the next
iteration.
The other example uses a thread event wait() call.

It seems that the example using wait() does not provide the same
precision as time.sleep() does (the counters does not sync, e.g. a
counter with a time interval of 0.1 does not count 10 times as fast as
a counter with a time interval of 1 second.

Any insights on how to do this the best way (thread safety and time
precision) would be greatly appreciated.

best
Oeyvind Brandtsegg

 

[Dennis Lee Bieber]

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.

--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Laurent Pointal]

Dennis Lee Bieber a écrit :

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.

 

[Dennis Lee Bieber]

realtime OSes != high level priority threads

Which is what my anecdote attempted to point out -- even at Windows'
highest "real time" priorities (THREAD_PRIORITY_TIME_CRITICAL on
REALTIME_PRIORITY_CLASS), I was getting hit with OS pauses.


OTOH, even an old Amiga (7MHz CPU assisted with DMA chips) was able
to handle ~32Kbps MIDI data; so timing shouldn't be /that/ critical.
Setting a "normal" (not "realtime") thread to Windows' Time Critical
level should be sufficient to put it at the head of the queue when a
sleep() expires.

Second approach might involve the internals of the interpreter --
the # of byte codes executed before a task switch takes place...
Minimizing task overhead from too short a period vs latency from too
long a period...
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Cameron Laird]

.
.
.

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).

.
.
.
Tcl and Erlang have interesting real-time capabilities, and
generally are regarded as "scripting languages".