Re: Setting the buffer size when using the Default Output AudioUnit
Re: Setting the buffer size when using the Default Output AudioUnit
- Subject: Re: Setting the buffer size when using the Default Output AudioUnit
- From: EJ Campbell <email@hidden>
- Date: Tue, 18 Feb 2003 17:00:20 -0800
Just a word of caution...
It's completely unintuitive, but signaling a pthread mutex might block
on Mac OS X. This is especially apparent on a single processor machine.
Blocking will cause audio dropouts if the blocked thread is handling an
audio proc. Mach semaphores do not have this problem, so I'd switch
over to them. A couple months back, I learned this the hard way. See
"MPNotifyQueue takes 500,000 nsec (worst case)" and "Can
pthread_cond_signal() block?" from the CoreAudio archives for all the
gory details. Basically, I started with the Multiprocessing API, found
its synchronization primitives lacking, then switched over to pthreads,
found it unusable, then finally moved to mach semaphores, which solved
my synchronization woes.
-EJ
On Tuesday, February 18, 2003, at 02:15 PM, Lionel Woog wrote:
Thanks to all.
Everything is now working fine with a mixture of pthread mutex and
condition
variables and mach real-time thread priority setting. I can easily
play a
cacophony of streams :-)
Even do low-latency scrub while playing.
Lionel
Hi Lionel
Have a look at this sample code :
/Developer/Examples/CoreAudio/HAL/MillionMonkeys/
This sample shows to create a secondary thread with the correct
priorities
(suitable for a feeder thread)
hth
Benjamin Golinvaux
www.arboretum.com
On Tuesday, Feb 18, 2003, at 22:08 Europe/Paris, Lionel Woog wrote:
Hi,
Threaded operations work, but without being superuser, I cannot set
the
thread priority above (below) 0, and this is inadequate for audio
operations. The slightest window move or scrolling will disrupt the
audio,
even though the decoder consumes no more than 20% of the CPU on a
450Mhz G4.
How can I get a high priority thread for my decoder.
Thanks,
Lionel
Lionel,
Although you can change the device frame size as Luke indicates
below,
to solve your problem I would recommend buffering ahead with the
decompression in a separate thread. I think trying to solve your
problem
by increasing the buffer size will just get you into trouble.
Chris Rogers
Core Audio
Apple Computer
In the <AudioUnit/AudioUnit.h> API's, get the AudioDeviceID of your
output unit (kAudioOutputUnitProperty_CurrentDevice.)
Armed with that, use the <CoreAudio/CoreAudio.h> API's set the
kAudioDevicePropertyBufferFrameSize on that AudioDeviceID to 4096,
being sure that 4096 falls in the range returned by
kAudioDevicePropertyBufferFrameSizeRange for that device.
On Tuesday, February 18, 2003, at 08:36 AM, Lionel Woog wrote:
Hi,
What can I do to change the number of frames requested by the
rendering
callback of the default output unit to be 4096 instead of 512.
At 512, my audio will not play smoothly, as I decompress data in
8192 frames
increments and this requires more CPU than can be done in
512/44100th of a
second.
I can get smooth playback by directly hooking up a rendered to the
hardware
audio device (and setting the buffer size appropriately), but
doing
so
prevents me from having more than one player going at a time.
Thanks for any help,
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.
_______________________________________________
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.
--
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.
_______________________________________________
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.