Re: Multi-threading and glitchless audio
Re: Multi-threading and glitchless audio
- Subject: Re: Multi-threading and glitchless audio
- From: Lionel Woog <email@hidden>
- Date: Wed, 26 Feb 2003 15:01:21 -0500
>
Hi all,
>
>
I have porting my sound-synthesis software to OS X and CoreAudio and have
>
been plagued by audio glitches, particular when there is a lot of UI activity
>
(I currently use Tcl/Tk Aqua for the UI).
>
The audio architecture is as followss: CoreAudio callback fires-off audio
>
processing activity in one or more other threads, and waits until those
>
threads complete before returning.
>
I have attempted to use the Mach real-time threading procedures to make the
>
audio-processing threads higher-priority than the UI, and I think I'm doing it
>
right (I took the code directly from either this list or a related list hosted
>
by Apple), but I still get cut outs. Trying to re-write the architecture of
>
my software to run its processing exclusively in the audio-callback procedure
>
would be rather difficult (especially considering that has already been
>
designed to run under Windows, Linux and SGI).
>
>
Is anyone else attempting to process audio in multiple threads, and if so
>
is there a trick to doing this that I'm missing?
>
>
Thanks and regards,
>
>
Amar Chaudhary
>
OpenSoundWorld Project
>
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.
This is what I am using for my real-time thread.
Note that the period must be small (hence the 0.01) to work.
// Make this thread real time
ttcpolicy.period = (UInt32) (0.01 * AudioGetHostClockFrequency()
* 8192.0 / player->srcInfo->baseSampleRate);
ttcpolicy.computation = 1000000 / 100;
ttcpolicy.constraint = ttcpolicy.period;
ttcpolicy.preemptible = 1;
if(KERN_SUCCESS != (ret = thread_policy_set(
mach_thread_self(),
THREAD_TIME_CONSTRAINT_POLICY,
(int *)&ttcpolicy,
THREAD_TIME_CONSTRAINT_POLICY_COUNT
)))
goto error;
This allocates about 1/3 CPU on a 450Mhz machine.
Do not use pthreads utex/condition varaibles, only mach semaphores for
signaling. You should have your worker thread run in parallel, not fired
off by the audio callback, as this will give you no improvement over just
doing the work during the callback.
The order is:
- Start the worker thread
- Start audio
- Play
- Stop audio
- Stop worked thread.
Typically, you will have the audio thread wait a certain amount of time for
data to be available, and the worker thread wait until one of its buffer is
empty to go back to work.
Lionel
--
Lionel Woog, Ph.D.
CTO
Adapted Wave Technologies, Inc.
email: email@hidden
phone: 212-645-0670
_______________________________________________
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.