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: Thu, 27 Feb 2003 17:22:03 -0500
Also worked for me.
Thread priority 63 using the mach set_priority call on the thread.
No hiccups whatsoever.
But I did have the weirdest thing happen yesterday. Kernel panic after
kernel panic whenever I accessed mach semaphores. The panic.log just said
w_queue deadlock and some mumbo jumbo.
I did not think I should be able to do this from user space. It went the
same way it came. I have no clue what happened, everything works now. If
anyone at Apple wants to look into it, I have my panic.log handy.
Lionel
>
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.
--
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.