| |||
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
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?
-ev
_______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/coreaudio-api/email@hidden
| References: | |
| >render inNumberFrames vs. pre/postRender inNumberFrames (From: Evan Olcott <email@hidden>) |
| Home | Archives | FAQ | Terms/Conditions | Contact | RSS | Lists | About |
Visit the Apple Store online or at retail locations.
1-800-MY-APPLE
Contact Apple | Terms of Use | Privacy Policy
Copyright © 2007 Apple Inc. All rights reserved.