I'm just asking these out of curiosity. I know you guys love these kinds of questions :)
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? I ran into this question after implementing a scripting engine for our commercial audio plugin using python, which uses a global lock to serialize access to it's data structures. 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? I hope I worded these well enough. Cheers! _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
