0
0

Hello! This FMOD Library is exactly what I have been looking for, and now I want to get my hands dirty with the raw floating data.. The callback is defined in my class as
function DSPCallBack (OriginalBuffer: Pointer; NewBuffer: Pointer;
Length, Param: Integer): Pointer; stdcall;

So I set up the following to initialize the callback.

DSPUnit := FSOUND_DSP_CREATE (@TfrmMain.DSPCallback,800,12345);
FSOUND_DSP_SetActive (DSPUnit,True);

I put a breakpoint in my callback, and sure enough it is getting called and just put some messages to show the address data that is being passed.. The problem here is this!
function tFrmMain.DSPCallBack (OriginalBuffer: Pointer; NewBuffer: Pointer;
Length, Param: Integer): Pointer; stdcall;
var I : TFSoundMixerTypes;
begin
I := FSOUND_GetMixer;
ShowMessage (IntToStr (Integer(I)));
ShowMessage (‘CallBack! 0x’ + IntToHex (Integer(OriginalBuffer),8 ));
ShowMessage (‘CallBack! 0x’ + IntToHex (Integer(NewBuffer),8 ));
ShowMessage (‘Callback! LENGTH : PARAM’+IntToStr (Length) + ‘:’+IntTOStr (Param));
result := OriginalBuffer;
end;
OriginalBuffer appears to point to valid data (no access violation)
NewBuffer is pointing to 0x00000400 (access violation!)
ALSO, where you see length:param, this message appears to show the inverse, in that it shows PARAM value, then a large integer. It then invariably returns an access violation on a read to 0x00000000 as well ๐Ÿ˜ก

I am using Delphi 6, and FMOD 3.70.
Any help would be greatly appreciated.

J

  • You must to post comments
0
0

Does anyone have any advice on this one? I can’t seem to find any issues regarding the implementation of my code, perhaps then that this is an FMOD issue. ๐Ÿ˜• Any thoughts?

  • You must to post comments
0
0

Well, after some investigation, and if anybody really cares…. ๐Ÿ˜• it would appear as though it [u:qgd868w0]can[/u:qgd868w0] be made to work, but as follows..

function tFrmMain.DSPCallBack (OriginalBuffer: Pointer;
ALength, Param: Integer): Pointer; stdcall;

Changed “length” to “ALength” (Length is a function.)

Also, it would appear as though newbuffer is always the same as originalbuffer, adding this declaration caused the aforementioned corruption. It must be removed in your declaration, and you just work on OriginalBuffer as a PSmallIntArray and it is working fine.. Too bad its -32767 to +32767 and not -1 to +1 but at least I can get the raw data, spend some time preparing it, and start working with it.

  • You must to post comments
0
0

The newbuffer is the buffer that gets changed, you shouldnt change the originalbuffer. And you have to declare newbuffer in your dsp callback function.

  • You must to post comments
Showing 3 results
Your Answer

Please first to submit.