0
0

[b:dcdt5egi]Edit:[/b:dcdt5egi] I think the problem might stem from the sizes of data types. I was using fwrite(ptr1, 1, len1, file), but when setting the second param to 2 or 4 the written wav has the correct length (still no sound, though).

Here are some details about how I’m creating/saving the sound, maybe they have some conceptual error?
[code:dcdt5egi]
exinfo.numchannels = 1;
exinfo.format = FMOD_SOUND_FORMAT_PCM16;
exinfo.defaultfrequency = WinLexDeviceManager::OUTPUTRATE;
exinfo.length = exinfo.defaultfrequency * sizeof(short) * exinfo.numchannels * maxSecondsToRecord;

result = fmodsystem->createSound(0, FMOD_2D | FMOD_SOFTWARE | FMOD_LOOP_NORMAL | FMOD_OPENUSER, &exinfo, &sound);
[/code:dcdt5egi]

Then I record the sound as done in the recordtodisk example, locking it like this:
[code:dcdt5egi]
sound->lock(lastrecordpos * exinfo.numchannels * 2, blocklength * exinfo.numchannels * 2, &ptr1, &ptr2, &len1, &len2);
[/code:dcdt5egi]

I seem to remember reading something on the forum about needing to cast the void *ptr1, *ptr2 to a certain type? But the recordtodisk example works without casting.

Thanks!


Initial post

Hello all,

I am working on a quite complex app and I have hit some problems with regard to recording sounds, doing processing on them, and writing them to disk as wavs.
Basically, the written wavs are filled with zeros; also, the length of the written wav does not match the length of the recording time.

I have to keep track of multiple simultaneous recordings, as well as asynchronously process commands for start/stop recording, that’s why the FMOD processing is isolated in a thread.
I have checked all this in a test app (based on the [b:dcdt5egi]recordtodisk[/b:dcdt5egi] example) where I only monitored two sound sources in my thread — that works perfectly.

I realise it’s hard to give an opinion without seeing the app, but maybe someone has encountered a similar problem and can give a suggestion?
Even knowing if this is an FMOD-related problem or not would help a lot!
(I will gladly provide source code information if someone has an idea)

Thank you,
–Cristina.[/code]

  • You must to post comments
0
0

[quote:ltdpkc94]I seem to remember reading something on the forum about needing to cast the void ptr1, *ptr2 to a certain type? But the recordtodisk example works without casting. [/quote:ltdpkc94]
That is probably for callbacks, that is unrelated to this current problem. The reason these are void
is because the type of data depends on the bit depth, i.e. 8-bit -> char, 16 bit -> short, 32 bit -> int. Here the actual type of the data doesn’t matter since fwrite takes a void* parameter so no casting is needed.

Comparing with the record to disk example you’ve added the FMOD_LOOP_NORMAL flag, i dont’ think that is needed.

I think the easiest way to debug this would be to put break points and inspect the contents of the buffers in the watch window. Try to work out if the zeros are coming from Sound::lock or whether something is happening to the data before it gets passed to fwrite.

  • You must to post comments
0
0

Thanks, Peter! At least this puts me closer to the right track.

I had tried debugging this before, but unfortunately, as a bit of Visual Studio/C++ noob, I have yet to discover how to see what’s in the place pointed to by the ptr1/2 pointers or the sound — the debugger only tells me "Cannot open children" or something like that. But this is not an fmod issue, so thanks again ๐Ÿ˜€

  • You must to post comments
0
0

Ok, so seeing as how the sound variable is defined as a pointer to FMOD::Sound, I tried to see the value of *sound in a debugger watch — it is {…}. But I don’t think this means much because this is what’s shown in the test application, which works.
("sound" itself contains a memory address as expected)

Is there any other way to debug the current contents of an FMOD::Sound variable?
Thank you!

  • You must to post comments
0
0

Kind of solved — problem between keyboard and chair ๐Ÿ˜‰
On a more serious note: the problem was not FMOD-related; my app is kind of complex so I omitted doing some necessary things.

  • You must to post comments
Showing 4 results
Your Answer

Please first to submit.