I am using the frameworks GSound, Ogre3D and Visual Studio 13 to try to set up the basic features of GSound.
First I initialize the shared pointers (a class for pointers for multithreading given by the rim framework, gsound is based on) for my sound classes and it seems that they are successfully initalized:
sSystem = rim::Shared<SoundPropagationSystem>::construct();
sScene = rim::Shared<SoundScene>::construct();
sSource = rim::Shared<SoundSource>::construct();
sListener = rim::Shared<SoundListener>::construct();
(I also tried this with a "standard" pointer using the "new"-keyword with the same result.)
After this I give the SoundDevice a Callback-Function-Pointer, so the sound devices buffer can be updated. This function is called from another thread outside of my main-Visual Studio 13-thread. When I assign it a function, the memory is still allocated.
Then when I debug into the callback-Function itself, the visual studio debugger says that it cannot read the memory and throws: "Unhandled exception: Access violation reading location 0x0000009D."
In the following code, only the parameters are accessable and the other pointers (here only sListener is used but the others are not readable too) are not readable:
Size TutorialApplication::soundOutput(rim::sound::SoundDevice& device, SoundBuffer& buffer, Size numSamples, const Time& time)
{
SoundListener listener = *sListener;
numSamples = sSystem->renderListener(&listener, buffer, numSamples);
numSamples = hdrFilter->process(buffer, buffer, numSamples);
return numSamples;
}
I assume that this is because the memory is only viewable for my main-Thread from VS13. After googling it, I only found solutions that did not work for me.
After looking into the thread window it shows that the outputSound-thread belongs to the same process as the thread where the pointers should be initialized.
Aucun commentaire:
Enregistrer un commentaire