Re: 192000 Hz won't render
Re: 192000 Hz won't render
- Subject: Re: 192000 Hz won't render
- From: Evan Olcott <email@hidden>
- Date: Fri, 30 Mar 2007 16:02:02 -0500
Well it turns out you guys were right - I needed to set the maximum
slices to render for ALL the AUs in the chain. I was wondering why
the HAL didn't do it (but it did), but there were a few other AUs in
the chain that needed it also.
Is there a reason why this can't be automagically done internally in
an AU when the stream format is set? The rate is right there...
-ev
On Mar 30, 2007, at 2:34 PM, William Stewart wrote:
On 30/03/2007, at 11:36 AM, Jeff Moore wrote:
On Mar 29, 2007, at 6:39 PM, Christopher Ashworth wrote:
On Mar 29, 2007, at 3:41 PM, Jeff Moore wrote:
One thing you might run into though is that to maintain an
~11.5ms IO cycle, the buffer size would increase from the
default of 512 frames to 2048 frames.
Dumb question just to make sure I'm following you: Which buffer
are you referring to here?
That would be the IO buffer size in the HAL for this device. AUHAL
inherits this buffer size as part of doing it's job, but other
AU's use a default size that is usually smaller in these
situations, which is why you need to tell them what to do.
If this is the case, you probably need to update each AU's
kAudioUnitProperty_MaximumFramesPerSlice property to be large
enough.
Are there guidelines for how to make sure we're setting the
kAudioUnitProperty_MaximumFramesPerSlice to ensure that it is the
right size for a particular I/O cycle of a particular device?
The way you phrase it above makes me think there is a
straightforward calculation that will give the right answer, but
if so I'm ignorant of it. (This is probably related to my
ignorance of where you got the 11.5ms number for the I/O cycle.)
Generally speaking, kAudioUnitProperty_MaximumFramesPerSlice
represents the largest number of frames you are going to call an
AU to render. This allows the AU to know how big to allocate its
internal buffers and what not. If this is too small, an AU might
refuse to honor a Render call that asks for more.
Not might - will :-)
You can get the I/O size from the output unit by making this call:
AudioUnitGetProperty (myAU, kAudioDevicePropertyBufferFrameSize,
kAudioUnitScope_Global, 0,
&numFrames, &outSize);
Then you set it:
result = AudioUnitSetProperty (unit,
kAudioUnitProperty_MaximumFramesPerSlice,
kAudioUnitScope_Global, 0, &numFrames , sizeof(numFrames ));
If there are any sample rate changes you have to adjust for that
(and in that case as well, we usually round up to - or add - a 4
frame safety margin as rate conversions will tend to call for
nicely sized sample buffers for vector processing).
Bill
--
Jeff Moore
Core Audio
Apple
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40apple.com
This email sent to email@hidden
--
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
______________________________________________________________________
____
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
engineering.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden