Re: Multi-threading and glitchless audio
Re: Multi-threading and glitchless audio
- Subject: Re: Multi-threading and glitchless audio
- From: "Amar" <email@hidden>
- Date: Thu, 27 Feb 2003 11:48:22 -0800
Yes, using pthread priority 63 over the time-constraint method does appear
to improve the situation greatly in that glitches are fewer and farther
between, although they still occur. It appears to correlate mostly with
screen redraws, excessive mouse activity, and disk activity. The worst is
switching between windows of the application. Is it possible that these
activities are causing the 63 thread to be late? Or do I still need to use
one of mach APIs rather than the pthread API to properly handle the thread
priorities?
Amar Chaudhary
OpenSoundWorld
email@hidden
osw.sourceforge.net
----- Original Message -----
From: "Bill Stewart" <email@hidden>
To: "Lionel Woog" <email@hidden>
Cc: "Amar" <email@hidden>; <email@hidden>
Sent: Wednesday, February 26, 2003 2:56 PM
Subject: Re: Multi-threading and glitchless audio
>
And I'll reiterate this yet again... Please take note and argue with me
>
if you disagree.
>
>
You should NOT need to use Time Constraint threads for this kind of
>
work, and using them will cause problems for all kinds of other real
>
time activities (like Audio and MIDI I/O)
>
>
It is sufficient to use a fixed priority thread of a priority of 63 to
>
be above most of the major activity that is going on in the system, and
>
still allows your I/O threads to run.
>
>
If you don't believe me * * * * * * * * *TRY IT* * * * * * * * * * -
>
don't just "think" you know better please:)
>
>
Bill
>
>
On Wednesday, February 26, 2003, at 12:01 PM, Lionel Woog wrote:
>
>
>> 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.
>
>
>
>
>
--
>
mailto:email@hidden
>
tel: +1 408 974 4056
>
>
________________________________________________________________________
>
__
>
"Much human ingenuity has gone into finding the ultimate Before.
>
The current state of knowledge can be summarized thus:
>
In the beginning, there was nothing, which exploded" - Terry Pratchett
>
________________________________________________________________________
>
__
>
_______________________________________________
>
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.
_______________________________________________
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.