Re: InputCallbacks and buffer size
Re: InputCallbacks and buffer size
- Subject: Re: InputCallbacks and buffer size
- From: Hari Seldon <email@hidden>
- Date: Wed, 30 Aug 2006 20:54:24 -0400
Okay, I can make that work. Do I have to write to the buffer that the
inputProc gets in the ioData, or can I create my own buffer and just
give back a pointer instead? If it's possible to just give a buffer
pointer, do I need to construct a new ABL, or can I just replace the
incoming one's buffer pointer? Lastly, if I do go a route of just
giving back pointers will the AUConverter properly clean up the memory
that it allocated for the buffer (I can handle the memory that I've
allocated)?
Thanks a lot
Quoting William Stewart <email@hidden>:
You can't provide more or less data to an audio unit than what is asks
for... you have to provide just what it asks for
On 30/08/2006, at 3:48 PM, Hari Seldon wrote:
So I now have smooth streaming audio by filling the buffer provided
by to the inputCallback (by the AUConverter), but really don't
like performing a memcpy for each 2k (512 frame) chunk of audio.
I was reading some examples where people made their own ABL filled
with data and assigned this to *ioData. I've tried this and it
works, but the results are not necessarily what I was looking for
since the AUConverter still thinks that data represents 512 frames
(verified by restricting my new ABL to 2k). The example I looked
at was just reassigning the count of frames to the new desired
amount but the inputProc's inNumberFrames is read only.
How do I tell it the new frame number so that I can pass larger
chunks of data?
Just want to get the audio running at less than 11-12% cpu on a mac
mini, as eventually adding codecs and video is going to require
more processing.
Thanks
Quoting Hari Seldon <email@hidden>:
Quoting William Stewart <email@hidden>:
On 18/08/2006, at 10:20 AM, Hari Seldon wrote:
Also, currently I copy data (interleaved signed int data) into
the buffer provided to the inputcallback; is this the best
approach?
You can reset the data pointers provided to you in the ABL - you then
have to keep those pointers valid until the next time the AU calls you
for data - that is the only clear time that you know that the AU is
finished processing your input.
How do you mean? I can setup the input callback to read the data from
a buffer that I own, just by passing it pointers to the buffer? How
is this done, as I haven't seen an example of it. I would be
interested in something like this as I'd prefer not to slow the system
down with another memcpy, if I already have the data awaiting playback
in a circular buffer.
Thanks
--
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:
This email sent to email@hidden