El dj 05 de 06 de 2008 a les 11:01 -0800, en/na Patrick Stinson va escriure: > On Thu, Jun 5, 2008 at 10:47 AM, Lars Luthman <[EMAIL PROTECTED]> wrote: > > On Thu, 2008-06-05 at 10:34 -0800, Patrick Stinson wrote: > >> I know that the rule is to never block in a real time audio thread, > >> but what about blocking for resources shared between real-time > >> threads? In the case of a sequencing app that uses one thread per > >> audio/instrument track (as most do), is it OK to share a lock between > >> real time scheduled tracks? > > > > Maybe. In theory it should be OK, I don't know enough scheduler magic to > > be certain. > > We haven't seen any drop in performance at all and are going to > release, so I suppose that's "good enough for us". The cool thing is > that python has been **AWESOME** (that's four starts, kids) in the > real time threads. The python lib is only accessed from our audio > kernel(s), with script source set with using downstream message > passing, and exceptions and redirected stdout using upstream message > passing.
I'm not sure to understand if your python code runs in the real-time thread or not. But if it's the case I wouldn't relay on the non-blocking performance of Python. Although garbage collector can be disabled the main problem, as I understand, is that Python is calling malloc all the time. Some info about it http://entitycrisis.blogspot.com/2007/12/is-hard-real-time-python-possible.html Real-time is all about predictability and worst case. For example, an audio file player that reads the file in the real-time thread will also be "good enough" most of the times (I've tested it). Till the very-important-demo day. Pau > > > >> Also, I've gathered are that adding app-thread => RT-thread > >> message-passing to avoid using locks while modify the application's > >> basic shared data structures is useless, since the real-time thread > >> will have to wait for execution of that code one way or another, given > >> the overhead of acquiring the lock is negligable. This would mean that > >> you should just use locks and assume the user will cope with hearing > >> small overruns when adding/removing audio components. True? Not true? > > > > Not true. The point with message-passing instead of locking a shared > > structure is that the RT thread doesn't access the shared structure in > > the first place - it has its own copy of the parameters it needs and can > > keep on producing audio until it receives a message, at which point it > > just changes its parameters in some RT-safe way (pointer swap etc) and > > goes on producing audio. No glitch. > > > > That makes sense. We are using a pointer swap in the message queue > using platform-specific atomic compare and swap functions. I wasn't > the one that implemented it, but the concept seems to make sense now. > > > > > --ll > > > > _______________________________________________ > > Linux-audio-dev mailing list > > [email protected] > > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev > > > > > _______________________________________________ > Linux-audio-dev mailing list > [email protected] > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
