Re: multithreaded mixer
Re: multithreaded mixer
- Subject: Re: multithreaded mixer
- From: Philippe Wicker <email@hidden>
- Date: Wed, 4 Feb 2004 08:00:38 +0100
On Wednesday, February 4, 2004, at 12:56 AM, Jeff Moore wrote:
Phiippe presents an excellent case, but unfortunately, it isn't going
to work too well when you push the machine hard.
Sad news :((
The reason why is that there is no "politically correct" way to block
the IO thread. No matter how you do it, you are still suspending the
IO thread. This mangles the scheduler's notion of the behavior of the
thread. It will appear like it is running way more often than the
scheduling parameters indicate it should be running.
This can cause things to not be pre-emptible when they should be and
will cause timing problems with other real time threads, such as the
IO thread of another device or the threads the MIDI server and it's
clients use.
I can understand that a thread which is declared as "periodic"
(thread_time_constraint_policy_data_t.period != 0) may "confuse" the
scheduler if it does not wake up periodically (which is how the IO
thread will behave if it is blocked). I can also understand that if one
IO thread is blocked, the scheduler may yield the CPU to another IO
thread which may lead to problems. On the other hand I cannot figure
why it could have a negative impact on the MIDI threads. Could tell us
more about this?
In short, don't ever block the IO thread. It is number one on the list
of "bad things" you can do.
Again, sad news ;((
The question then is: is this scheduler the best one for the kind of
applications we are all writing? The way it works - combined with the
pull audio flow model - prevents the efficient use of a multi-processor
machine because the DSP work will always be executed in one thread and
therefore by one processor at any given time. I know that sometimes the
work can be delegated to other threads (and other processor) without
blocking the IO thread (the feeder thread of a "ping-pong" file reader
such as PlayAudioFile is an example). This kind of "delegation" implies
that the audio can be fetched some amount of time before it will be
processed by the IO thread (one chunk ahead in the case of the file
reader). This is obviously not applicable when low latency are needed
(e.g. for live playing).
To go back to the original question (split the DSP work between
different threads), the only solution I can see which satisfies the
"don't ever block the IO thread" constraint is to make both subgraphs
run in their own thread and "push" the audio into a private ring
buffer. The code executed in the context of the IO thread has then to
pull the audio from both ring buffers, mix it and return it to the HAL.
When the IOProc is called, the code here could pass the IOProc
parameters to these two threads using 2 non blocking queues (one for
each thread). This solution adds a latency which may be as much as an
IOProc buffer size. The other bad news is that the synchronization of
the worker threads with the IOProc needs a mutex/condvar couple or a
mach semaphore. In both cases, a lock must be taken either by the IO
thread or the worker thread which may lead to block the IO thread
(although for a very short amount of time). It is true however that in
this particular case the probability of such a blocking is very low and
may be neglected (???).
Jeff Moore
Core Audio
Apple
_______________________________________________
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.
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.