Re: ExtAudioFileSetProperty ClientDataFormat error on iPhone
Re: ExtAudioFileSetProperty ClientDataFormat error on iPhone
- Subject: Re: ExtAudioFileSetProperty ClientDataFormat error on iPhone
- From: William Stewart <email@hidden>
- Date: Tue, 13 Oct 2009 19:38:32 -0700
On Oct 13, 2009, at 11:11 AM, tahome izwah wrote:
Hi Doug,
please find my comments inline below.
2009/10/12 Doug Wyatt <email@hidden>:
On Oct 12, 2009, at 12:03 , tahome izwah wrote:
Thanks, but why does the documentation ( http://bit.ly/yKBDB ) say
that kAudioFormatFlagIsFloat is "Available in iPhone OS 2.0 and
later"
??
That's just a constant; formats are described exactly the same way
on the
desktop and phone. Availability of the constant is not the same
thing as API
features described by the constant.
Another way to put this: It's possible to describe some pretty
esoteric PCM
formats with an AudioStreamBasicDescription, but AudioConverter only
supports a certain subset of those.
Ok makes sense. "Available" in this sense would have to be taken
literally, and not be confused with "supported". Is this what you're
getting at?
Basically... for instance, we provide definitions for various flavours
of MPEG-4 audio codecs (celp, hvxc, etc) that we don't ship
implementations for. If someone else were, then we'd expect them to
use the definitions for a given format that we provide.
Another way to deal with this - you can still get float32 audio file
data, and we would describe a file with this data correctly, using an
ASBD with float32 flags, etc. If you tried to convert this using an
audio converter it would fail, because we haven't supported float32
sample formats on the device at this point. But your code could deal
with it if you really needed to, so having the defintion and types
available is useful
Bill
And secondly, is there a reason why the simulator behaves
differently
than the device?
There are a lot of ways in which the simulator behaves differently
form the
device. In this case it's because even though the simulator is
running all
of the audio units etc. in integer/fixed-point formats, at some point
AudioToolbox has to talk to the HAL in floating point, and it likes
to use
AudioConverter for those conversions. Sorry that we didn't find a
way to
hide that.
Ok I see. I was just confused about this apparent inconsistency.
Thanks for the explanations!
--th
_______________________________________________
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
_______________________________________________
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