• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: AudioConverterFillComplexBuffer and temporary stream exhaustion
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AudioConverterFillComplexBuffer and temporary stream exhaustion


  • Subject: Re: AudioConverterFillComplexBuffer and temporary stream exhaustion
  • From: Doug Wyatt <email@hidden>
  • Date: Thu, 8 Apr 2004 16:54:57 -0700

On Apr 8, 2004, at 16:19, Michael Thornburgh wrote:
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.

Yes, you do need to refresh the ABL before calling, because on exit the mDataByteSizes are altered to reflect how much output was actually produced.

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.

This is puzzling me, we've had a couple of reports of this, but I do not observe it in my own test cases. You're not doing any encoding, are you? (in that case, then yes, data can get buffered inside the converter according to the need of the codec to emit only complete packets) For simple sample rate conversion, however, only a few sample frames get buffered.

If you could tell me
- what formats you're converting from and to
- how much data you are requesting at a time
- how much data you are supplying at a time

-- or just send me your code -- pelase do, I'd like to get to the bottom of this.

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).

I'm hoping there's either something you or we are doing wrong that, once fixed, would make this unnecessary...

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.


References: 
 >AudioConverterFillComplexBuffer and temporary stream exhaustion (From: Michael Thornburgh <email@hidden>)
 >Re: AudioConverterFillComplexBuffer and temporary stream exhaustion (From: Doug Wyatt <email@hidden>)
 >Re: AudioConverterFillComplexBuffer and temporary stream exhaustion (From: Michael Thornburgh <email@hidden>)

  • Prev by Date: Re: AudioConverterFillComplexBuffer and temporary stream exhaustion
  • Next by Date: Re: MusicPlayerStop kills default AU callback?
  • Previous by thread: Re: AudioConverterFillComplexBuffer and temporary stream exhaustion
  • Next by thread: [OT] IBM XL Compiler
  • Index(es):
    • Date
    • Thread