0
0

Hi,

I’m looking to load a FMOD_SAMPLE and then extract it’s data but in such a way the data in the same format that a DSP callback would get it in the inbuffer parameter.
I tried doing this by locking the sound data, copy the contents to a int16_t buffer, and then normalizing&storing the data by dividing each 16 bit sample by 32767.0f.

Here’s the code I’ve written to do this:

[code:2xsph8ae]
unsigned int numSamples = 0;
int bitsPerSample = 0;
track->sound_->getFormat(NULL, NULL, NULL, &bitsPerSample);
track->sound_->getLength(&numSamples, FMOD_TIMEUNIT_PCM);
track->sound_->getLength(&mappedMemorySize_, FMOD_TIMEUNIT_PCMBYTES);
assert(bitsPerSample == 16);
mappedMemorySize_ *= 2; // multiple by two because we’re storing 16 bit normalized values in 32 bit floats
printf("Num samples: %i\tBits per sample: %i\n", numSamples, bitsPerSample);
mappedMemory_ = new char[mappedMemorySize_]; // in my actual code, this is a memory mapped buffer, hence the name.

unsigned int bytesRead = 0;
int16_t* mem = 0;
float* output = (float*)mappedMemory_;
track->sound_->lock(0, mappedMemorySize_ / 2, (void**)&mem, 0, &bytesRead, 0);
int i = 0;
for (i = 0; i < bytesRead / 2; ++i) {
    int16_t sample = mem[i];
    output[i] = ((float)mem[i]) / 32767.0f;
    printf("%f\n", output[i]);
}
track->sound_->unlock(mem, 0, bytesRead, 0);

[/code:2xsph8ae]

and then in my dsp callback, instead of filtering the inbuffer, I filter the memory mapped buffer instead (so that I can jump forward or backward any arbitrary amount). But with how the code is now, the playback is like 4x slower and sounds very deep.

I feel like the problem lies in my conversion from int16 samples to floating channels?

  • You must to post comments
0
0

So you were correct in that the problem was definitely a sampling issue. The problem lies in the fact that the data acquired from Sound::lock() is in the audio file’s native format, so the frequency/samplerate of the data is 44100. On iPads (my target platform) the sound card’s sample output rate is 24000, so FMOD must be doing a downsampling internally to accommodate this difference. Is there a way to either a.) downsample the data from lock() without losing quality (like FMOD does internally), or b.) change the output sample rate so that the DSP callback is called more frequently (I tried System::setSoftwareFormat which didn’t seem to affect it at all)?

Edit – I figured out how to change the output sample rate, but there’s a lot of problems (skipping, weird speed ups) when trying to play two sounds. So, if anyone could help me with downsampling the data that would be great! Thanks

  • You must to post comments
0
0

Can I fix the sample rate by changing the frequency of FMOD_SAMPLE Sound?

  • You must to post comments
0
0

error converting from 16-bit to float errors would have incorrect amplitude (loudness). errors in speed and pitch indicare resampling issues. I expect that the source sound has a different sample rate to the output.

  • You must to post comments
Showing 3 results
Your Answer

Please first to submit.