Show Posts
1
Audio / Re: sf::SoundRecorder derived class
« on: December 11, 2017, 09:35:02 pm »
Hi eXpl0it3r, thanks for reply.
If I delete the cMicRecord class, there is no crash. I guess it would crash even whitout my derived class if I had mixed 64 and 32 bits libraries. Also, I remember I only downloaded the x86 version. So, I don't think the problem comes from here.
I thought it wasn't usefull (there is nothing in it), there is the complete implementation:
In another class I derived the sf::SoundStream class and it produces the same problem. Here too, if I delete the constructor, it doesn't crash anymore... And even if the constructor has nothing in it, it crashes.
EDIT 1:
I downloaded the last SFML version on Git, built it, etc.
Now I can see better where it crashes:
It crashes here, it appears that m_mutex is NULL.
In my implementation I have a m_mutex too and if I remove it, it crashes anyway at this line, because of m_mutex implemented in sf::AlResource (for "Very first global device initialization").
EDIT 2:
I removed everything in my class, except the (empty) constructor and the two pure virtual member functions (empty too).
It crashes anyway when locking the mutex of sf::AlResource.
EDIT 3:
Okay, it's not about a constructor. It seems that the mutex implemented in sf::AlResource isn't properly initialized. I tried to insert my derived class a way its constructor is called the later I could but even if its mutex isn't NULL, it crashes anyway. So instead of a composition model like, I tried an external agregation with a pointer of my derived class (and allocate at Singleton runtime). And it works...
So I think the derived class constructor calls the sf::AlResource constructor too soon, therefore its mutex isn't totally initialized.
I'll try to find why.
EDIT 4:
I still don't know why the mutex pre-implemented in sf::AlResource isn't properly initialized when its constructor is called, but because I need my derived class to be agregated to a class used a long time after the game's starts, the problem isn't anymore.
Anyway, if somebody know what's the problem and could explain me, I would be glad to understand.
If I delete the cMicRecord class, there is no crash. I guess it would crash even whitout my derived class if I had mixed 64 and 32 bits libraries. Also, I remember I only downloaded the x86 version. So, I don't think the problem comes from here.
I thought it wasn't usefull (there is nothing in it), there is the complete implementation:
Code: [Select]
cMicRecord::cMicRecord()
{ // <- Error here
m_bRecording = false;
std::vector<std::string> availableDevices = sf::SoundRecorder::getAvailableDevices();
if (availableDevices.size() > 0
&& this->setDevice(availableDevices[0]))
m_bOperational = true;
else
m_bOperational = false;
}
cMicRecord::~cMicRecord()
{
m_bRecording = false;
m_bOperational = false;
stop();
}
bool cMicRecord::onStart()
{
this->setProcessingInterval(sf::milliseconds(100));
if (m_bOperational
&& this->isAvailable())
{
m_bRecording = true;
return true;
}
else
return false;
}
bool cMicRecord::onProcessSamples(const sf::Int16* samples, std::size_t sampleCount)
{
//const sf::Int16* samples = reinterpret_cast<const sf::Int16*>(static_cast<const char*>(packet.getData()) + 1);
//std::size_t sampleCount = (packet.getDataSize() - 1) / sizeof(sf::Int16);
//sf::Lock lock(SINGLETON.m_micStreamer.m_mutex);
//std::copy(samples, samples + sampleCount, std::back_inserter(SINGLETON.m_micStreamer.m_samples));
return true;
}
void cMicRecord::onStop()
{
m_bRecording = false;
}
bool cMicRecord::isRecording()
{
return m_bRecording;
}
In another class I derived the sf::SoundStream class and it produces the same problem. Here too, if I delete the constructor, it doesn't crash anymore... And even if the constructor has nothing in it, it crashes.
EDIT 1:
I downloaded the last SFML version on Git, built it, etc.
Now I can see better where it crashes:
Code: [Select]
> *****.exe!sf::priv::MutexImpl::lock() [EnterCriticalSection(&m_mutex);]
*****.exe!sf::Mutex::lock() [m_mutexImpl->lock();]
*****.exe!sf::Lock::Lock(sf::Mutex & mutex) [m_mutex.lock();]
*****.exe!sf::AlResource::AlResource() [Lock lock(mutex);]
*****.exe!sf::SoundRecorder::SoundRecorder() [CONSTRUCTOR]
*****.exe!cMicRecord::cMicRecord() [CONSTRUCTOR]
It crashes here, it appears that m_mutex is NULL.
In my implementation I have a m_mutex too and if I remove it, it crashes anyway at this line, because of m_mutex implemented in sf::AlResource (for "Very first global device initialization").
Code: [Select]
"SFML/System/Win32/MutexImpl.hpp"
void MutexImpl::lock()
{
EnterCriticalSection(&m_mutex); // <-- err
}
EDIT 2:
I removed everything in my class, except the (empty) constructor and the two pure virtual member functions (empty too).
It crashes anyway when locking the mutex of sf::AlResource.
EDIT 3:
Okay, it's not about a constructor. It seems that the mutex implemented in sf::AlResource isn't properly initialized. I tried to insert my derived class a way its constructor is called the later I could but even if its mutex isn't NULL, it crashes anyway. So instead of a composition model like, I tried an external agregation with a pointer of my derived class (and allocate at Singleton runtime). And it works...
So I think the derived class constructor calls the sf::AlResource constructor too soon, therefore its mutex isn't totally initialized.
I'll try to find why.
EDIT 4:
I still don't know why the mutex pre-implemented in sf::AlResource isn't properly initialized when its constructor is called, but because I need my derived class to be agregated to a class used a long time after the game's starts, the problem isn't anymore.
Anyway, if somebody know what's the problem and could explain me, I would be glad to understand.