My FSOUND_Close() function crashes.
I tried to find the cause of crash and I figured out it is this piece of code that makes the Close function crash:

[code:dwvp3et0] FSOUND_Sample_Lock(samp,offset,length,&ptr1,&ptr2,&len1,&len2);

So if I drop this code, the Close function doesn’t crash. I guess I’m doing something terribly wrong here but I don’t know what. The code seems to work pretty good. It is not perfect but I’m still tuning it. And I only have 1 thread (if that might be important). But my question is: “what am I doing wrong here?”

Thanks again for the help. It is appreciated!

  • You must to post comments






that’s what I saw, copied and pasted on my code…but if the program is working I’ve got no idea…I’m not so skilled at programming actually.

BTW, I’ve got a question myself…I’m using a sample for recording which is 2000 samples long(I allocated so). I did

if (!FSOUND_Record_StartSample(recSample, TRUE)) /* start recording and make it loop also */
int recordpos = FSOUND_Record_GetPosition();
if(recordpos >= 2000)
FSOUND_Sample_Lock(recSample, 0, 2000, &ptr1, &ptr2, &len1, &len2);
memcpy(fmodBuf, ptr1, len1);
FSOUND_Sample_Unlock(recSample, ptr1, ptr2, len1, len2);
......//and use fmodBuf for whatever I want to do
} while(!terminateRec);

I wanted to send fmodBuf through the net whenever the 2000 samples of recSample is filled. But when I checked recordpos the biggest I saw was 1920, so none inside the if(){…} was executed. Is there any other way to do this or anything I’m misunderstanding?? If anybody has an idea, please help…

  • You must to post comments

Well, that’s good…
But Isn’t there any way I can lock the sample exactly with the length(fixed) of the sample itself…? I made the sample size a little bigger than the buffer size, but I hear the loss, which is probably caused near the end of the buffer.

  • You must to post comments

[quote="brett":2nao5pwq]i think it is because you are ignoring len1 and len2
If you check the docs you will notice that you can only write the amount returned to len1.
You are probably writing too much data and corrupting memory. maybe you have a samples/bytes mixup or your offset is too large.[/quote:2nao5pwq]

you are 100% right. The ignoring of len1 and len2 caused the crashes.
The ampersands didn’t make any difference but I changed it anyway.
Thanks brett and geewoo!

geewoo, about your problem:

When you start recording in a loop, the position of the recordpointer (FSOUND_Record_GetPosition) is augmented in blocks, depending on your loop length. So every time you call FSOUND_Record_GetPosition, the position will be increased, depending on the number of blocks that were read since the last time you called the function.

But if the position reaches the end of the sample (in your case 2000) it will wrap around and start at 0 again. This is the reason your if-test is never executed. Only if your recordposition is exactly 2000 (which happens almost never), your if-test succeeds.

Try this:
after this line: int recordpos = FSOUND_Record_GetPosition();
add: printf(“recordpos: %i\n”,recordpos);
or cout << “recordpos: ” << recordpos << “\n”;

you’ll see for example this:

So your recordposition will never be more than 2000.

You can solve this problem by replacing:

if (recordposition >= 2000)
if (recordposition >= 1000)
for example

So you write blocks of 1000 samples to your buffer.
I’m not really a good programmer either but I hope all this makes sense.

Greetz and thanks again for the help (both of you).

  • You must to post comments

Thanx for the reply. I’ve tested that and you’re right…That’s why I tried smaller buffer size and all that…
But then how will I be able to avoid losing the rest of my samples, for example if the alllocated size is 2000 and I change the condition to
if(recordpos >= 1920) …? I’d have to get access to the 80 samples, but in the next loop locking would start from the beginning of the sample again, so I would lose the 80. Is there another way to do this?
In sum, my question is this:
How can I lock the continuously recorded sample data ‘seamlessly’?

  • You must to post comments

You can keep a variable with your old recordpos. If the new recordpos is smaller than the old one, it means your sample has wrapped. In that case you know, the old recordpos and you know the length of your sample, so you know how many samples remain at the end of the sample and you have a pointer to the beginning of the remaining samples (your old recordpos).

For example:

recordpos = FSOUND_Record_GetPosition();
if (recordpos > oldrecordpos)
copy (recordpos-oldrecordpos) samples to your own buffer
else //recordpos has wrapped
copy (samplelength-oldrecordpos) samples to your own buffer
copy the wrapped recordpos samples to your own buffer
oldrecordpos = recordpos;

I hope all this makes a little sense to you and if you don’t understand what I’m saying, just reply here and I’ll try to explain differently.
I don’t know if it is the best way to do the job but I’m experimenting with the same code right now and it seems to work pretty fine.

And a little remark:
defining your recordpos in the while loop isn’t such a good idea, try to allocate it outside the while loop and just change its value every loop. It consumes less memory ๐Ÿ˜‰

  • You must to post comments

Thanx again, I’m almost done with the recording part…
But now that the sample length is varied(depending on when the FSOUND_Record_GetPosition is called), the sample length on the playback part should be varied, too. How did you code the playback part(if you’re finished)?
So far I’ve been using a custom sample with a fixed length(2000). I lock the sample, upload the received buffer, and play it. I doubt if I can work it out this way any more, ’cause I can’t allocate the sample with different length every time I receive the data through the net(I’m playing it in a remote computer).
Any ideas…?? My question is, shortly,
“How do I play the incoming buffers of raw data, with various length?”

  • You must to post comments

You don’t send them with variable length ๐Ÿ˜‰

I sent you a PM. I’ll try to help you out.

  • You must to post comments
Showing 7 results
Your Answer

Please first to submit.