Re: multithreaded mixer
Re: multithreaded mixer
- Subject: Re: multithreaded mixer
- From: Philippe Wicker <email@hidden>
- Date: Tue, 3 Feb 2004 23:04:17 +0100
On Tuesday, February 3, 2004, at 10:03 PM, Brian Willoughby wrote:
>
Philippe,
>
>
Excellent tutorial! Some nice tricks in there.
>
>
[ Now the tricky part. When the stub "output callback" is called by
>
[ the HAL, it should store somewhere the parameters passed to the
>
[ IOProc (so that they can be read by the code of stub threads 1 and
>
[ 2) and signal **both** ReqSem1 and ReqSem2 and then wait on, say,
>
[ AckSem1. When ReqSem1 and 2 are signaled, stub threads 1 and 2 are
>
[ woken up immediately (they are real time constrained) after IOProc
>
[ thread call to the wait on AckSem1, and executes each on one
>
[ processor (provided than no other real time thread is ready at the
>
[ same moment). When stub thread 1 has finished its rendering it
>
[ signals AckSem1 and wait again on ReqSem1, same for stub thread 2
>
[ which signals AckSem2 and goto wait on ReqSem2. The IOProc thread is
>
[ woken up when AckSem1 is signaled and goto wait on AckSem2 which may
>
[ have already been signaled (by stub thread 2) or will be later when
>
[ stub thread 2 has finished its rendering. Anyway, when the IOProc
>
[ thread returns from the wait on AckSem2 both subgraphs have been
>
[ rendered. The IOProc thread has then to mix audio coming from both
>
[ subgraphs and then return from its IOProc.
>
>
Is there any way for the IOProc thread to wait on both AckSem1 *and*
>
AckSem2
>
at the same time? I seem to remember that the wait call can be given
>
more than
>
one semaphore. Then again, perhaps combining semaphores that way
>
means that
>
wait will return when either AckSem1 *or* AckSem2 is signalled, but
>
will not
>
wait for both. In that case, I suppose the only way is with two calls
>
to wait.
>
>
I suppose I could just go look this up and try it out, but I thought I
>
would
>
run the idea by you...
I seem to remember that some other kind of semaphores allows what you
suggest, the SysV semaphore set API. I think this API is implemented in
Mac OS X, but is not the recommended one (recommended API for inter
process synchronization is the POSIX API) I just know one API for mach
semaphore: semaphore_wait (semaphore_t sem). It takes only one
argument. An optimized approach could have been to use one semaphore
initialized with a count of -2. The waiter would be woken up after 2
calls to semaphore_signal and then would reset the semaphore to -2, etc
... The mach semaphore API does not allow to set the sem count other
than when creating it. A solution based on a POSIX condition variable
could do it. The predicate associated with the condition would be a
"and" between two bools, each of these bools being set by each one of
the stub threads. The predicate could also be (counter == 0). This
counter should set to -2 at the beginning of each IO cycle by the
IOProc thread, and atomically incremented in each stub threads. I
didn't take a lot of time to write the first answer. Just put down a
rough solution that seems to work and there is of course room for
improvement :))
>
>
Brian
>
>
Philippe Wicker
email@hidden
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.