0
0

Hi,
i would get wave datas then apply SoundTouch time stretch (tempo and pitch change) and play the modified sample. It’s possible? How can i do that?
I’ve already tried with fsmod::sound::setFrequency but the result is not good for my project so i need more control on changing velocity.
Thanks!

  • You must to post comments
0
0

If you want to compensate for the pitch change when you stretch the sound you can use the FMOD pitch shift DSP.

If there is some other reason why you want to use SoundTouch you can. I would reccomend creating a custom DSP. Open the sound file as a FMOD::Sound and manually read the data using Sound::readData. So, inside the DSP read callback, you read the Sound file and then feed that sound data through SoundTouch and the feed the output of SoundTouch into FMOD.

-Pete

  • You must to post comments
0
0

[quote="peter":2od387lz]If you want to compensate for the pitch change when you stretch the sound you can use the FMOD pitch shift DSP.

If there is some other reason why you want to use SoundTouch you can. I would reccomend creating a custom DSP. Open the sound file as a FMOD::Sound and manually read the data using Sound::readData. So, inside the DSP read callback, you read the Sound file and then feed that sound data through SoundTouch and the feed the output of SoundTouch into FMOD.

-Pete[/quote:2od387lz]

Thank you for the reply.
I don’t want to compensate the pitch. My problem is that setFrequency is too slow to update the sound. I think that buffer size is too big… i’ve tried with System::setDSPBufferSize but it doesn’t work.

  • You must to post comments
0
0

Yeah, buffersize and numbuffers are the biggest factors for latency. The default is 1024×4, which is ~4000 samples which is almost 100ms at 48kHz. Does that number fit what you are seeing? You can reduce the latency (at the expence of CPU).

256×4 should be reasonably safe, that would take it down to ~25ms. You can go even lower if you like, but keep an eye on the CPU usage of your application.

  • You must to post comments
0
0

[quote="peter":1fscusg2]Yeah, buffersize and numbuffers are the biggest factors for latency. The default is 1024×4, which is ~4000 samples which is almost 100ms at 48kHz. Does that number fit what you are seeing? You can reduce the latency (at the expence of CPU).

256×4 should be reasonably safe, that would take it down to ~25ms. You can go even lower if you like, but keep an eye on the CPU usage of your application.[/quote:1fscusg2]

Quoting the docs:

[quote:1fscusg2]
Default = 1024. (milliseconds = 1024 at 48khz = 1024 / 48000 * 1000 = 21.33ms)
[/quote:1fscusg2]

I’ve tried with 768 and according to the above calculations the update should be every 16 ms… but the latency doesn’t change.
When i should use setDSPBufferSize? After System::init but before something else?

  • You must to post comments
0
0

The total latency is that number (21.33) times the number of buffers, I rounded it up to 100ms, it’s really closer to 85ms.

With 768 you would get 16×4 = 64ms. It’s probably better to stick to powers of 2, so: 1024, 512, 256, 128 etc.

-Pete

  • You must to post comments
0
0

[quote="peter":g7yr0cwj]The total latency is that number (21.33) times the number of buffers, I rounded it up to 100ms, it’s really closer to 85ms.

With 768 you would get 16×4 = 64ms. It’s probably better to stick to powers of 2, so: 1024, 512, 256, 128 etc.

-Pete[/quote:g7yr0cwj]

Thank you Pete, now it works!

  • You must to post comments
Showing 6 results
Your Answer

Please first to submit.