Re: AudioConverterFillComplexBuffer and temporary stream exhaustion
Re: AudioConverterFillComplexBuffer and temporary stream exhaustion
- Subject: Re: AudioConverterFillComplexBuffer and temporary stream exhaustion
- From: Michael Thornburgh <email@hidden>
- Date: Thu, 8 Apr 2004 16:19:39 -0700
thanks, doug. this got me on the right track.
the paramErr was indeed caused by AudioConverterFillComplexBuffer
setting my ABL's mDataByteSizes to 0. i added a fixer-upper to reset
their proper sizes, which solved that problem.
when QA1317 said "any data that was converted will also be returned to
the caller," i was hoping that would mean "if you signal a temporary
exhaustion of input data, asked for 1000 frames, but only enough data
was available to generate 700 frames, then you'd get back 700 frames."
it appears, though, that the AC won't do the partial conversion that i
want. if i ask for 1000 frames, i'll either get 1000 frames and noErr,
or i'll get 0 frames and my propagated error code.
so now i'm fooling around with
kAudioConverterPropertyCalculateOutputBufferSize and keeping track of
how many input frames are left partially digested inside the Audio
Converter, to estimate the number of output frames to ask for. that
way, the conversion will succeed, the "temporary input exhaustion"
condition will never arise, and hopefully i'll get almost all the data
without leaving too much in limbo inside the Audio Converter, and
especially without leaving a little more each time inside the Audio
Converter.
what would be nice is if there was an AC property that was "given this
many input frames, and previous input frames currently in
AudioConverter Limbo, how many whole output frames can i request
without needing more fresh input?" or a boolean property that
indicated that it was OK to do partial conversions (that is, to return
as many frames as could be converted immediately, even if that was
fewer than the number requested).
-mike
On Apr 8, 2004, at 12:43 PM, Doug Wyatt wrote:
On Apr 7, 2004, at 21:12, Michael Thornburgh wrote:
It's not clear from your description what the difference between #1
and #2 is. What do you mean by "the first time?" You should return an
error as soon as you are temporarily out of data. When you return an
error, don't return any data -- it will be ignored.
The callback should look something like this (in pseudocode):
if I am at end-of-stream:
set *ioNumberPackets to 0
set up returned ABL to contain zero-length buffers (without looking
it up, not sure if this necessary)
return noErr
if I have anything at all to provide:
set *ioNumberPackets
set up returned ABL to point to source data (making sure
mDataByteSize matches *ioNumberPackets)
return noErr
if I don't have anything to provide right now:
set *ioNumberPackets to 0 (may not be necessary)
return "no more input right now" error (any nonzero value)
But in any case, the key seems to be the paramErr you're getting when
calling AudioConverterFillComplexBuffer after having returned an error
from your input proc.
It is possible that if you don't provide enough input, no output will
be produced and your previously-supplied input remains buffered inside
the converter.
Be aware that you must reset mDataByteSize in the output buffer lists
before every call to AudioConverterFillComplexBuffer.
The CAAudioFile class in the latest SDK contains working code that
"pushes" data through a converter.
i can supply my code to any interested parties (or post to the list
if people want -- it should squeeze under the 12K size limit), but
it'll require MTCoreAudio.framework to compile and link. :)
If you're still stuck and mail me your code, I'll take a look.
Doug
_______________________________________________
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.