Re: AudioConverterFillComplexBuffer and temporary stream exhaustion
Re: AudioConverterFillComplexBuffer and temporary stream exhaustion
- Subject: Re: AudioConverterFillComplexBuffer and temporary stream exhaustion
- From: Doug Wyatt <email@hidden>
- Date: Thu, 8 Apr 2004 12:43:38 -0700
On Apr 7, 2004, at 21:12, Michael Thornburgh wrote:
i'm trying to signal to AudioConverterFillComplexBuffer from my
AudioConverterComplexInputDataProc, using procedure #2 from technical
Q&A QA1317, that i'm currently out of input data, but i'll have more
later. the thing i'm actually trying to accomplish is to use an
AudioConverter as a pushing direction sample rate converter -- that
is, given some input frames, immediately convert them into the
appropriate number of output frames, while maintaining all the state
necessary to seamlessly join together with the next chunk in the
future.
here's what i'm doing: i'm asking AudioConverterFillComplexBuffer to
convert WAY more frames than can be obtained from converting source
frames on hand, into a destination ABL (which is big enough to hold
the large number of frames i've asked for). in my
AudioConverterComplexInputDataProc, i connect the ioData ABL to my
source frame buffer, and set *ioNumberDataPackets to the number of
on-hand source frames. i've tried the following from here:
1) return noErr. i'm called again to supply the remainder. i set
*ioNumberDataPackets to 0, configure ioData for 0-length buffers, and
return not-noErr. for not-noErr, i've tried eofErr, -1, 'MBcD', and
'foo '.
2) return an error as in the second part of #1, the first time.
i'm not called again.
3) return noErr. i'm called again, and set *ioNumberDataPackets to
0, configure ioData for 0-length buffers, and again return noErr. i'm
called several more times and do the same thing.
for #1 and #2, once i return the error,
AudioConverterFillComplexBuffer returns and propagates that error code
to me, but it tells me that 0 frames were converted. further, a
future, identical call to AudioConverterFillComplexBuffer returns -50
(paramErr).
for #3, that's the way to signal permanent end-of-stream according to
QA1317, and it seems to have that effect. when i do that, it does
actually give me the portion of samples it was able to convert, but
future calls to AudioConverterFillComplexBuffer return noErr and
0-frames-converted, and doesn't call my callback, which is what you'd
expect if the input stream had permanently ended.
from reading QA1317, it's not 100% clear whether you're supposed to do
#1 or #2, or whether they're actually equivalent, but it does seem
like at least one of them should work. is there a secret i'm missing,
or something obvious from my description that i'm doing wrong?
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
--
Doug Wyatt
Core Audio, Apple
_______________________________________________
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.