5 Jun
2008
5 Jun
'08
4:48 p.m.
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.
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.
--ll