mail archive A mailing list for developers using Core Audio and MIDI APIs (C or Java) on MacOS X
coreaudio-api.lists.apple.com
(List home) (Recent threads) (100 other Apple lists)
Subscription Options
- RSS or Atom: Read-only subscription using a browser or aggregator. This is the recommended way if you don't need to send messages to the list. You can learn more about feed syndication and clients here.
- Conventional: All messages are delivered to your mail address, and you can reply. To subscribe, send an email to the list's subscribe address with "subscribe" in the subject line, or visit the list's homepage here.
- Moderate traffic list: up to 30 messages per day
- This list contains about 8,086 messages, beginning Oct 2009
- 1 messages added yesterday
Report the Spam
This button sends a spam report to the moderator. Please use it sparingly. For other removal requests, read this.
Are you sure? yes no
kExtAudioFileProperty_CodecManufacturer and client formats
Ad
Hey folks, I've been noodling around and looking for ways to make my ExtAudioFile reading go a bit faster on devices w/ the hardware AAC codec. I had a hunch that ExtAudioFile wasn't using the hardware AAC decoder by default, and noticed that iOS 4 added a nifty new property for me to assert this fact: kExtAudioFileProperty_CodecManufacturer The header seems to indicate it was provided for _encoding_ using hardware, but I'm interested in _decoding_ using the hardware. So, I tried it, and it didn't work. :) However, it's not the request of the hardware decoder that fails---it's the setting of kExtAudioFileProperty_ClientDataFormat that fails. I'm setting a deinterleaved floating-point format for reading, and ExtAudioFileSetProperty(ClientDataFormat) is returning 'perm'. I suspect that since, according to the header, setting the ClientDataFormat "triggers the creation of the codec," this could be related to my not having access to the hardware at the time of the call. However, an alternate explanation might be that the hardware decoder simply isn't compatible with my use of floats as the client data format? Any insight from the CoreAudio team, or anyone else that's successfully used this, would be great! Cheers, Chris Liscio http://supermegaultragroovy.com Learn _your_ music with Capo: http://capoapp.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/coreau... This email sent to
On Aug 24, 2010, at 7:39 , Christopher Liscio wrote:
> Hey folks,
>
> I've been noodling around and looking for ways to make my ExtAudioFile reading go a bit faster on devices w/ the hardware AAC codec.
>
> I had a hunch that ExtAudioFile wasn't using the hardware AAC decoder by default, and noticed that iOS 4 added a nifty new property for me to assert this fact: kExtAudioFileProperty_CodecManufacturer
>
> The header seems to indicate it was provided for _encoding_ using hardware, but I'm interested in _decoding_ using the hardware.
>
> So, I tried it, and it didn't work. :)
>
> However, it's not the request of the hardware decoder that fails---it's the setting of kExtAudioFileProperty_ClientDataFormat that fails.
>
> I'm setting a deinterleaved floating-point format for reading, and ExtAudioFileSetProperty(ClientDataFormat) is returning 'perm'.
>
> I suspect that since, according to the header, setting the ClientDataFormat "triggers the creation of the codec," this could be related to my not having access to the hardware at the time of the call.
>
> However, an alternate explanation might be that the hardware decoder simply isn't compatible with my use of floats as the client data format?
>
> Any insight from the CoreAudio team, or anyone else that's successfully used this, would be great!Chris,
The 'perm' error is indeed a result of an attempt to create the AudioConverter and failing due to lack of permission to use the hardware decoder.
The header is correct; kExtAudioFileProperty_CodecManufacturer only supports use of hardware encoders.
Doug
On Aug 24, 2010, at 8:27 PM, Doug Wyatt wrote: > The 'perm' error is indeed a result of an attempt to create the AudioConverter and failing due to lack of permission to use the hardware decoder.OK, that's what I feared. > The header is correct; kExtAudioFileProperty_CodecManufacturer only supports use of hardware encoders. D'oh! I filed rdar://8352659 to track this one. I'm not sure if the hardware supports MP3 decoding, but it'd be a huge performance win for some of the stuff I'm working on which does some offline audio analysis. Cheers, Chris Liscio http://supermegaultragroovy.com Learn _your_ music with Capo: http://capoapp.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/coreau... This email sent to
I know it is more work, but if this is a critical feature for you, you can use the AudioQueue's offline render functionality. It allows you to use the hw codecs, and gives you back buffers of decoded audio you can then use as you need too. There is a tech note about this with some example code
BillOn Aug 25, 2010, at 6:00 AM, Christopher Liscio wrote:
>
> On Aug 24, 2010, at 8:27 PM, Doug Wyatt wrote:
>> The 'perm' error is indeed a result of an attempt to create the AudioConverter and failing due to lack of permission to use the hardware decoder.
>
> OK, that's what I feared.
>
>> The header is correct; kExtAudioFileProperty_CodecManufacturer only supports use of hardware encoders.
>
> D'oh! I filed rdar://8352659 to track this one.
>
> I'm not sure if the hardware supports MP3 decoding, but it'd be a huge performance win for some of the stuff I'm working on which does some offline audio analysis.
>
> Cheers,
>
> Chris Liscio
> http://supermegaultragroovy.com
> Learn _your_ music with Capo: http://capoapp.com _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Coreaudio-api mailing list
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/coreau...
>
> This email sent to
Dumb question--- If the HW codecs can work with the AudioQueue API, could I not also get hardware decoding by using a pure AudioConverter, or is there some kind of secret sauce in the AudioQueue that isn't exposed yet? I certainly wouldn't mind going that route, as the 'extra work' would be a bit more compatible with the code I'll have to inevitably dig into and change... Also, digging through the archives, I noticed you said that ExtAudioFile _does_ have decoding access: http://lists.apple.com/archives/coreaudio-api... Colour me confused! ;) Thanks, Chris Liscio http://supermegaultragroovy.com Learn _your_ music with Capo: http://capoapp.comOn Aug 25, 2010, at 1:36 PM, William Stewart wrote: > I know it is more work, but if this is a critical feature for you, you can use the AudioQueue's offline render functionality. It allows you to use the hw codecs, and gives you back buffers of decoded audio you can then use as you need too. There is a tech note about this with some example code > > Bill > > On Aug 25, 2010, at 6:00 AM, Christopher Liscio wrote: > >> >> On Aug 24, 2010, at 8:27 PM, Doug Wyatt wrote: >>> The 'perm' error is indeed a result of an attempt to create the AudioConverter and failing due to lack of permission to use the hardware decoder. >> >> OK, that's what I feared. >> >>> The header is correct; kExtAudioFileProperty_CodecManufacturer only supports use of hardware encoders. >> >> D'oh! I filed rdar://8352659 to track this one. >> >> I'm not sure if the hardware supports MP3 decoding, but it'd be a huge performance win for some of the stuff I'm working on which does some offline audio analysis. >> >> Cheers, >> >> Chris Liscio >> http://supermegaultragroovy.com >> Learn _your_ music with Capo: http://capoapp.com _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Coreaudio-api mailing list >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/coreau... >> >> This email sent to >
On Aug 27, 2010, at 9:16 , Christopher Liscio wrote: > Dumb question--- > > If the HW codecs can work with the AudioQueue API, could I not also get hardware decoding by using a pure AudioConverter, or is there some kind of secret sauce in the AudioQueue that isn't exposed yet? > > I certainly wouldn't mind going that route, as the 'extra work' would be a bit more compatible with the code I'll have to inevitably dig into and change...There are issues of arbitrating access to the hardware codecs. Originally the only way to use them, ever, was through AudioQueue. Then last year the hardware AAC encoder became available on some devices, without a software version available. What's there for Extended Audio File was designed to provide access to the hardware AAC encoder.> Also, digging through the archives, I noticed you said that ExtAudioFile _does_ have decoding access: > > http://lists.apple.com/archives/coreaudio-api... > > Colour me confused! ;)Bill misspoke. Doug