• 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
Fwd: render inNumberFrames vs. pre/postRender inNumberFrames
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: render inNumberFrames vs. pre/postRender inNumberFrames


  • Subject: Fwd: render inNumberFrames vs. pre/postRender inNumberFrames
  • From: Evan Olcott <email@hidden>
  • Date: Mon, 26 Jun 2006 19:05:56 -0500

I think this might count as a bug report, but I thought I'd check here first:
---


I have an AUFormatter with it's render callback set to a routine in my app, gathering data to render.
The same AUFormatter has a pre/post render notify callback attached to it as well, assigning automation (in the pre-render, technically).


When I render a file who's sample rate is different than the hardware's rate, I change the sample rate of the AUFormatter's input stream, which gathers data accordingly:
- if the machine is running at 44.1kHz and the source file is 96kHz, the render call gets asked for the appropriate number of samples (if the machine has a 512 sample buffer, the render call gets asked for 1114+ samples at a time, which is fine)


However, the pre- and post- render callbacks always reference a 512 sample buffer! This makes me calculate the sample range incorrectly, thus my ramped automation is off - I'm getting the wrong length to work with.

Shouldn't the pre- render calls represent the number of samples it's about to ask for, instead of the system's buffer size?

Would I be forced to do some "length math" to get the proper number of samples about to be asked for so I can preRender my automation properly?

Further reading shows that the *preRender* and *postRender* calls are always in reference to the *output* of the audio unit to which they are attached. That explains why I'm getting buffer size & info based on the AUFomatter's output buffer size, not on what the AU is "about to grab". Moderately inconvenient, but that's the way it is.


Just writing it out so it goes into the mailing list DB in case someone searches for this.

-ev

_______________________________________________
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


  • Follow-Ups:
    • Re: render inNumberFrames vs. pre/postRender inNumberFrames
      • From: William Stewart <email@hidden>
References: 
 >render inNumberFrames vs. pre/postRender inNumberFrames (From: Evan Olcott <email@hidden>)

  • Prev by Date: render inNumberFrames vs. pre/postRender inNumberFrames
  • Next by Date: Re: render inNumberFrames vs. pre/postRender inNumberFrames
  • Previous by thread: render inNumberFrames vs. pre/postRender inNumberFrames
  • Next by thread: Re: render inNumberFrames vs. pre/postRender inNumberFrames
  • Index(es):
    • Date
    • Thread