I’m working with a time stretching DSP, and wondering whether it’s possible to resize the output buffer (since slowing it down will lead to more samples, I need more space). I think not, but I’m trying to verify.
Alternatively, my callback must accumulate the extra samples generated, returning to the DSP chain only the number it was passed, but then how can I make fmod continue requesting them after it thinks it’s reached the end of the song?
If a 10-sec. song gets time stretched to 20-sec., making it twice the number of samples, fmod will think it’s done before I’m out of samples, right?
Any advice would be appreciated.
- mrisher asked 14 years ago
Thank you for the reply. It makes sense that I wouldn’t be able to alter the # samples, but I thought I’d check.
In what way is the DSP system still ticking? Fmod is no longer firing the DSP callback function. Is there a way to inject my samples into the output stream even though Fmod thinks it’s done?
Presently, I have a stream_end_callback set to fire when fmod reaches the end of the song. However, my timestretch buffer still has some residual samples to play, and would load them up if the DSP_callback got called again (which it doesn’t).
I suppose I could do some klugey things like fake the fmod seek pointer backwards so I get some extra DSP cycles, or load up another, blank stream after the first one finishes, but it seems a little messy. Did you have something else in mind?
Ah, that makes sense. I was forgetting there is a central engine.
Okay, then the [perhaps obvious] next question is the opposite: if I’m accelerating a sample using DSP, how can my callback get extra samples?
In other words, if the DSP engine passes me 1024 samples and expects that many in return, I need access to 2048 samples if I’m reverse-time-stretching. Any suggestions on a look-ahead DSP?
Please login first to submit.