| Thanks for your reply.
Being able to set a ramped event on the mixer's output volume parameter would be a great solution, but, looking through the earlier thread, it appears that no one was able to get that approach to work.
All I am trying to accomplish for now, is to stop the fileplayers without any click or artifact from abruptly cutting the playback, then load new audio files and resume playback as quickly as possible. I wrote a fade in 100 steps using an NSTimer, but the audio threads have higher priority and the fade would sometimes run beyond the time taken to reload the fileplayers.
Advice from this list was to tie all critical timing to msampletime, which I can get from one of the fileplayerAU's. If I poll the fileplayer's CurrentPlayTime property from outside the callback, ie. with a simple do...loop I get values that stay the same for a while then increase by 512 samples. I'm thinking this is the buffer size that the fileplayer is using.
At the moment, I've moved the original fade out into an untimed do...loop with more steps. At least with this the order of calls stays in place, but some files still click when stopping. This is a little too rough an approach to be able to evaluate if fading the mixer's output volume is the best way to get a clean file stop.
I'll try to get timestamps from inside the callback loop and then schedule a fade based on that timing. Otherwise, it looks like I will need to fade the actual sample values down to zero.
If any of this seems misguided, I'm open to any suggestions.
regards,
Robert Carroll RSM Records Toronto
On Jan 7, 2014, at 6:30 PM, Aran Mulholland wrote: Specifying your own callback will break the chain but you can manually call render on the FilePlayerAU from inside your callback. If all you are looking to do is fade out audio, wouldn't it be better to turn down the volume of the mixer?
|