Re: Accessing audio samples from Audio Queue Buffers
Re: Accessing audio samples from Audio Queue Buffers
- Subject: Re: Accessing audio samples from Audio Queue Buffers
- From: Doug Wyatt <email@hidden>
- Date: Thu, 10 Sep 2009 14:35:42 -0700
For some preliminary context: on the phone, the hardware codec tend to
take longer to decode but consume less power. Software codecs tend to
execute more quickly but are more CPU and power-intensive.
Software codecs are available at any time via AudioConverter,
including the higher-level APIs which use AudioConverter -- AudioQueue
and ExtAudioFile.
But hardware codecs are only available via AudioQueue. (Exception: as
of OS 3.1, you can use the AAC hardware encoder via ExtAudioFile...)
So, if you've been using AudioQueueOfflineRender to decode and post-
process AAC or MP3, you may want to try using AudioConverter to do a
software decode instead.
Doug
On Sep 10, 2009, at 14:16 , Steven Winston wrote:
So Doug, This means that we'd be using the 'software' decoders and
not the 'hardware' decoders? So there's really no benefit towards not
including a software decoder library as it's not really going to the
hardware decoder, then providing PCM back to the OS prior to sending
it to the DAC?
Have a feeling you can't answer this in its' entirety so just a quick
explanation about what's available would be most helpful.
Thanks,
Steve
On Thu, Sep 10, 2009 at 2:12 PM, Doug Wyatt <email@hidden> wrote:
Oops, I was just reminded that we *do* have a software MP3 decoder
as of
3.0. I don't know what I was thinking.
sorry for the confusion
Doug
On Sep 10, 2009, at 13:55 , Doug Wyatt wrote:
The new capability in 3.1 is to be able to use the hardware AAC
*encoder*,
*only* ... nothing has changed with respect to hardware decoders.
We do have
some software decoders available as of 3.0, but MP3 isn't one of
them.
As for the difference in MP3 decode rates, that's interesting. If
you
like, file a bug and attach files which illustrate the problem and
we'll
investigate.
thanks,
Doug
On Sep 9, 2009, at 17:43 , Steven Winston wrote:
Well in my tests I'm noticing that some audio when encoded with the
exact same format are filling the audioqueueofflinerender buffers
at
different rates than other files encoded with the same format. I
didn't investigate too far into this however, it seems like there
must
be some overhead that prevents the callback happening at a more
consistant rate between the files.
So for instance if file A is encoded as a MP3 44.2 khz 16 bit 2
chan
file and file B is also encoded as a MP3 44.2 khz 16 bit 2 chan
file
when they are decoding file A might decode at an appreciable rate
slower than file B when using AudioQueueOfflineRender. If that
problem doesn't exist, in the ExtAudioFile, then I can scrap the
external software MP3 decoder in my project.
On Wed, Sep 9, 2009 at 5:33 PM, William Stewart<email@hidden>
wrote:
On Sep 9, 2009, at 5:28 PM, Steven Winston wrote:
That's awesome! However, a question, is this solution going to
suffer
from the same different files of the exact same format decode at
different rates problem?
"same different" - sorry, but I don't understand the problem you
are
referring too.
I'll start digging through 3.1 docs and will
eagerly await the further details.
On Wed, Sep 9, 2009 at 5:22 PM, William
Stewart<email@hidden> wrote:
One of the new things in iPhone OS 3.1 is that you can use
ExtAudioFile
to
read and write compressed data where you may need to use a
hardware
assisted
codec (such as AAC encoding) to do so.
Details are forthcoming, including some example code - have a
look in
the
tech notes and release notes for the 3.1 release
Bill
_______________________________________________
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