Last Thursday I gave a talk on embedding python as an audio scripting application at the San Francisco Public Library for the PyGameSF meet-up.

It had been a while since I’d put anything up in the community on this topic, as I’ve sort of sat down as an ambitious developer after getting totally burnt out in the music industry. But, I was reminded of how much interest there is surrounding this stuff when the attendees excitedly tossed a multitude of quality questions out as I spoke.

While the technical details of the Play engine are protected under NDA, I have posted the slides from my talk here:
http://trac2.assembla.com/pkaudio/attachment/wiki/EmbeddedInterpreter/PyGame%20Talk.ppt

Process Migration

The two most important points of interest from the talk were taken directly from my experience embedding Python in a commercial audio thread:

1) PyEval_EvalFrame takes up 0.4% of our audio thread’s CPU time when executing some control-rate callbacks with some rather simple looping and app logic. That’s a REALLY BIG DEAL. It means that CPython is very fast at executing the language sytax.

2) Lock contention from the GIL causes CPU spikes, but only at low latencies. In the talk I pushed process migration as the logical solution, and shouted my schpeil on how once upon a time no one thought office apps could be written in javascript…and also how the same company that broke that barrier recently started using multiple processes like candy in their own web browser.

I mentioned that I was almost done porting our engine to use a separate python process per audio thread in order to get around the GIL. I can’t wait to write up the details of the implementation, as I think we all need to start thinking about multiple processes as a way of life.