0
0

I am developing for the Wii with FMOD version 4.20.05.

I am getting a crash when trying load the event fev file. We have set up a file system such that we load all our resource files into memory on startup, so we would like FMOD to load files from our system.

Here is the initialization:
[code:1zakli8c]
FMOD_ASSERT(result = Memory_Initialize(memblock, MEMSIZE, NULL, NULL, NULL));

FMOD_ASSERT(result = EventSystem_Create(&m_pEventSystem));

FMOD_ASSERT(result = m_pEventSystem->init(64, FMOD_INIT_NORMAL, 0, FMOD_EVENT_INIT_NORMAL));

FMOD_ASSERT(result = m_pSystem->setFileSystem(fileOpen, fileClose, fileRead, fileSeek, -1));

FMOD_ASSERT(result = m_pEventSystem->load("fmod/examples.fev", 0, 0));
[/code:1zakli8c]

The program breaks at the last line of the initialization code (where m_pEventSystem->load() is called).

The stack trace outputs this:
load__Q24FMOD12EventSystemFPCcP19FMOD_EVENT_LOADINFOPPQ24FMOD12EventProject (0x801CDF30)

Assembly line:
801CDF30: 818C0008 lwz r12,8(r12)

My open file callback:
[code:1zakli8c]
FMOD_RESULT F_CALLBACK DriverAudio::fileOpen(const char *name, int unicode, unsigned int *filesize, void **handle, void **userdata)
{
if (name)
{
FileHandle* fp = DriverFileSystem::getSingleton().getFileHandle(name);
CNTFileInfo* fileInfo = &fp->m_fileInfo;

    if (!fp)
    {
        return FMOD_ERR_FILE_NOTFOUND;
    }

    CNTSeek(fileInfo, 0, CNT_SEEK_END);
    *filesize = CNTTell(fileInfo);
    CNTSeek(fileInfo, 0, CNT_SEEK_SET);

    *userdata = (void *)0x12345678;
    *handle = fp;
}

return FMOD_OK;

}
[/code:1zakli8c]

My file read callback:
[code:1zakli8c]
FMOD_RESULT F_CALLBACK DriverAudio::fileRead(void *handle, void *buffer, unsigned int sizebytes, unsigned int *bytesread, void *userdata)
{
if (!handle)
{
return FMOD_ERR_INVALID_PARAM;
}

if (bytesread)
{
    FileHandle* fp = (FileHandle *) handle;
    CNTFileInfo *fileInfo = (CNTFileInfo *) (&fp->m_fileInfo);

    memcpy(buffer, fp->m_pData, fp->m_uSize);
    *bytesread = fp->m_uSize;

    if (*bytesread < sizebytes)
    {
        return FMOD_ERR_FILE_EOF;
    }
}

return FMOD_OK;

}
[/code:1zakli8c]

I’m not too sure what the bytesread value should be…I’ve already read the contents of the file into a buffer which is why I’m using memcpy.
[i:1zakli8c]FileHandle[/i:1zakli8c] is a simple structure containing a pointer to the data that has been read in ([i:1zakli8c]m_pData[/i:1zakli8c]) and the file size ([i:1zakli8c]m_uSize[/i:1zakli8c]). When I output the value, it is the correct size of the file in question.

Here’s the end of my Console output:
[code:1zakli8c]
FMOD: SystemI::init : done

FMOD: EventSystemI::init : done
FMOD: EventSystemI::load : name_or_data fmod/examples.fev
FMOD: File::flip : BAD LENGTH RETURNED FROM FILE READ FUNCTION, TERMINATING.
FMOD: EventSystemI::load : fileversion = 0x00390000 (0x00070000, 0x00390000)
FMOD: File::flip : BAD LENGTH RETURNED FROM FILE READ FUNCTION, TERMINATING.
FMOD: EventGroupI::load : name_len = 33583973
FMOD: EventSystemI::load : eventgroupi->load (num=2, count=0)

[/code:1zakli8c]

Using my debugger, I can see the EventSystem::load() function does return FMOD_OK in this case, whereas in my previous attempts (using incorrect loading strategies) it would show a large negative result, indicating to me that it had not returned yet.

Can someone help me pinpoint the problem, or maybe suggest a better way to load files from memory?

  • You must to post comments
0
0

Hi, are you just memcpy’ing from the start of you buffer each time? That obviously won’t work. You’re supposed to copy from the relevant position in your data to the buffer fmod provides, with the amount of bytes it asked for (not the whole file).

It looks to me like your memcpy should be more like

[code:25ewn3ym]
*bytesread = sizebytes;
if (fp->m_currentPosition + *bytesread >= fp->m_uSize)
{
*bytesread = fp->m_uSize – fp->m_currentPosition;
}

memcpy(buffer, fp->m_pData + fp->m_currentPosition, *bytesread);

[/code:25ewn3ym]

the currentposition would also be updated with the seek callback.

  • You must to post comments
0
0

if you want to load files from memory why don’t you just use fmod’s build in support for loading files from memory? load() takes a pointer to memory.

  • You must to post comments
0
0

Using load() to load a file from memory was one of the first things I tried, but also resulted in a crash, which is why I resorted to using file callbacks. Ideally I would rather use this approach than callbacks, so if we can find some way around the crash that would be great.

It went something along these lines:
[code:32v63k07]
FileHandle* fp = DriverFileSystem::getSingleton().getFileHandle("fmod/examples.fev");

FMOD_EVENT_LOADINFO loadInfo;
memset( &loadInfo, 0, sizeof(loadInfo));
loadInfo.loadfrommemory_length = fp->m_uSize;

result = m_pEventSystem->load((const char*) fp->m_pData, &loadInfo, 0);
[/code:32v63k07]

So when debugging, load doesn’t return a valid value; [i:32v63k07]result[/i:32v63k07] reads as a large negative number. That’s the line where the program breaks.

  • You must to post comments
0
0

your data has to be corrupt somehow, you should probably provide a logfile output here (ie fmodexL/fmod_eventL output) and make sure in a debugger the first few characters of the memory you are passing to the load function are "FEV" (the file’s signature)

  • You must to post comments
0
0

Here’s my log output:
[code:2s89tpu3]
<< RVL_SDK – EXI debug build: Jul 30 2008 18:54:23 (0x4199_60831) >>
<< RVL_SDK – SI debug build: Jul 30 2008 19:00:39 (0x4199_60831) >>

Revolution OS
Kernel built : Oct 2 2008 03:25:44
Console Type : NDEV 2.1
Firmware : 53.16.17 (7/11/2008)
Memory 152 MB
MEM1 Arena : 0x80334a60 – 0x817ff7a0
MEM2 Arena : 0x90000800 – 0x975e0000
<< RVL_SDK – OS debug build: Oct 2 2008 03:25:44 (0x4199_60831) >>
<< RVL_SDK – SC debug build: Jul 30 2008 19:01:52 (0x4199_60831) >>
<< RVL_SDK – NAND debug build: Sep 11 2008 17:26:15 (0x4199_60831) >>
<< RVL_SDK – DVD debug build: Jul 30 2008 18:54:17 (0x4199_60831) >>
<< RVL_SDK – VI debug build: Sep 11 2008 17:25:54 (0x4199_60831) >>
<< RVL_SDK – WPAD debug build: Sep 11 2008 17:25:55 (0x4199_60831) >>
<< RVL_SDK – KPAD debug build: Sep 11 2008 17:25:38 (0x4199_60831) >>
<< NW4R – G3D debug build: Oct 6 2008 17:18:17 (0x4199_60831) >>
<< RVL_SDK – GX debug build: Sep 11 2008 17:25:33 (0x4199_60831) >>
<< RVL_SDK – CNT debug build: Jul 30 2008 19:02:21 (0x4199_60831) >>
FMOD: EventSystemI::init : maxchannels = 64. flags = 00000000
FMOD: SystemI::init : FMOD Ex Version: 00042005
FMOD: SystemI::init : maxchannels = 64, flags = 00000000, extradriverdata = 0x00000000
FMOD: SystemI::close :
FMOD: SystemI::close : Stop all sounds
FMOD: SystemI::close : Remove miscllaneous DSP stuff.
FMOD: SystemI::close : done.

FMOD: OutputRevolution::init : Initializing.
<< RVL_SDK – AI debug build: Jul 30 2008 18:53:35 (0x4199_60831) >>
AIInit(): DSP is 32KHz
Initializing AX
<< RVL_SDK – AX debug build: Jul 30 2008 18:53:42 (0x4199_60831) >>
Initializing AXAlloc code module
Initializing AXVPB code module
Initializing AXSPB code module
Initializing AXAux code module
Initializing AXCL code module
Initializing AXOut code module
<< RVL_SDK – DSP debug build: Jul 30 2008 18:54:12 (0x4199_60831) >>
FMOD: OutputRevolution::init : DVD read priority set to 1
FMOD: Thread::initThread : Initializing Wii Controller Update Thread. priority 3
FMOD: Thread::initThread : – Stacksize 16384. Stack pointer 0x00000000 : usesemaphore = 0 : sleeptime = 6
FMOD: Thread::callback : * Wii Controller Update Thread started
FMOD: Thread::initThread : done.
FMOD: SystemI::init : Set up software engine
FMOD: OutputRevolution::start : Aquiring Left/Mono voice for software output
FMOD: OutputRevolution::start : Aquiring Right voice for software output
FMOD: Thread::initThread : Initializing FMOD mixer thread. priority 3
FMOD: Thread::initThread : – Stacksize 32768. Stack pointer 0x00000000 : usesemaphore = 0 : sleeptime = 10
FMOD: Thread::callback : * FMOD mixer thread started
FMOD: Thread::initThread : done.
FMOD: SystemI::init : Set up emulated output
FMOD: SystemI::init : create the channel pool
FMOD: SystemI::init : Set up streamer
FMOD: Thread::initThread : Initializing FMOD stream thread. priority 2
FMOD: Thread::initThread : – Stacksize 49152. Stack pointer 0x00000000 : usesemaphore = 0 : sleeptime = 10
FMOD: Thread::callback : * FMOD stream thread started
FMOD: Thread::initThread : done.
FMOD: OutputRevolution::setReverbProperties : setting STANDARD reverb.
FMOD: OutputRevolution::setReverbProperties : turned off STANDARD reverb.
FMOD: OutputRevolution::setReverbProperties : setting STANDARD reverb.
FMOD: OutputRevolution::setReverbProperties : turned off STANDARD reverb.
FMOD: OutputRevolution::setReverbProperties : setting STANDARD reverb.
FMOD: OutputRevolution::setReverbProperties : turned off STANDARD reverb.
FMOD: OutputRevolution::setReverbProperties : setting STANDARD reverb.
FMOD: OutputRevolution::setReverbProperties : turned off STANDARD reverb.
FMOD: OutputRevolution::setReverbProperties : setting STANDARD reverb.
FMOD: OutputRevolution::setReverbProperties : turned off STANDARD reverb.
FMOD: SystemI::init : done

FMOD: EventSystemI::init : done
FMOD: EventSystemI::load : name_or_data FEV1
Warning: DVDOpen(): file ‘FEV1’ was not found under /.
FMOD: EventSystemI::load : fullpath = FEV1
ASSERT FAILED!
exp: result == FMOD_OK
file: CapyDriverAudio.cpp
func: Capy::DriverAudio::FMOD_ASSERT(FMOD_RESULT)
line: 12
msg: FMOD error! (23) File not found.

[/code:2s89tpu3]

I also get the File not found error when I try to load the file using the pathname rather than a pointer, which is strange since I can read other files fine which are stored in the same directory.

  • You must to post comments
0
0

Setting the size of the loadinfo struct seems to have resolved this problem:
[code:1yq0glzy]FMOD_EVENT_LOADINFO loadinfo;
loadinfo.size = sizeof(loadinfo);[/code:1yq0glzy]

Thank you for your assistance, Brett.

  • You must to post comments
0
0

ah right, thanks for the update. I think we might remove cbsize as we’re not really consistently using it across all structs and we have a policy of not changing structs inside a stable branch revision anyway.
Between branches we dont expect dlls to be binary compatible.

Removing this variable will just avoid hurdles/support requests when trying to get code to work.

  • You must to post comments
Showing 7 results
Your Answer

Please first to submit.