Hi,

when I quit my program, the app hangs in _al_win_input_exit-function at WaitForSingleObject(ack_event, INFINITE). Found some old stuff in this forum here, but don't know whether the solution is still the same...
So what could be my mistake.... forget to free memory ?

I use MSVC 2005 and only the sound stuff from allegro 4.9.8 .

Hope there's help ;-)

Cheers, I

Can you provide a simple program that illustrates this behavior?

Maybe allegro.log has some useful info?

>> Can you provide a simple program that illustrates this behavior?

I have no simple program. This sound stuff is part of our C#-App. We use allegro in a c++ - SoundManager-dll. That is wrapped in a SoundManagerWrapper-Dll ( managed, assemply ) and this we use in a C#-app... no way to provide usefull source code... what a pity..

The log says:

// LOG START

ALLEGRO_SYSTEM_INTERFACE created.
al-winput INFO: Input thread started.
Render-to-texture: 1
ALSA not available on this platform (error code: 1)
sample matrix:
1.000000 0.000000
0.000000 1.000000

// LOG END

Funny, because I take the autodetect to install the audio
> al_install_audio(ALLEGRO_AUDIO_DRIVER_AUTODETECT) , so no need to say NO ALSA ..

You may not have one, but we're going to need one. Its a common request. We need the simplest example possible that shows the issues you are having, otherwise we can't know who's problem it is.

What a pity.... but there's no program actually, because I only make init, create global voice and global mixer and create a stream:

// *****************************************
// INIT
// *****************************************

if ( !al_init() )
{
LOG_ERROR("Could not init allegro !");
return ;
}

// init sound stuff
if ( al_install_audio(ALLEGRO_AUDIO_DRIVER_AUTODETECT) )
{
LOG_ERROR("Could not init sound !");
return ;
}

// CREATE VOICE
m_GlobalVoice = al_create_voice( 44100, ALLEGRO_AUDIO_DEPTH_INT16, _al_count_to_channel_conf(2) );

m_GlobalMixer = al_create_mixer( 44100,
ALLEGRO_AUDIO_DEPTH_FLOAT32, _al_count_to_channel_conf(2) );

// attach mixer to voice
if ( al_attach_mixer_to_voice(m_GlobalVoice,m_GlobalMixer) != 0)
LOG_ERROR("Error, can't attach voice to mixer !!");

// *****************************************
// Create Stream and attaching to GlobalMixer
// *****************************************

m_pStream = al_create_stream( buffer_count, m_pSoundResource->GetSampleCount(), m_pSoundResource->GetFrequency(), _al_word_size_to_depth_conf(word_size), _al_count_to_channel_conf(channels) );

al_attach_stream_to_mixer(m_GlobalMixer, m_pStream)

That's all for the source code. There're no other filling/playing stuff.
A bit tricky is to use allegro in a managed wrapper dll, because net doesn't support tls. Initially we use to use allegro 4 as static lib in our soundmanager.dll, but this went wrong with this version. So now we use dlls and had to redefine this Mingw define in tls.c from

#if defined ALLEGRO_MINGW32 && ( \
_GNUC_ < 4 || (__GNUC__ == 4 && _GNUC_MINOR_ < 2) || \
(__GNUC__ == 4 && _GNUC_MINOR == 2 && _GNUC_PATCHLEVEL < 1))

to

#if defined OUR_NO_NATIVE_TLS || (ALLEGRO_MINGW32 && ( \
__GNUC__ < 4 || (__GNUC__ == 4 && _GNUC_MINOR_ < 2) || \
(__GNUC__ == 4 && _GNUC_MINOR == 2 && _GNUC_PATCHLEVEL < 1)) )

So the tls is supported in our dll.But don't know the side effects of this hack...

Yes, that's the keys.... and maybe you can help me ?

So make a program from that code, and see if you have the same problem.

You mean I should create another program with the same code to check its behavior ?

hmmm....... any other ideas ?

You should create a simple Allegro based program using ONLY the allegro code you've been using, and a little extra code to test that code.

That means the bug could be in any of those other pieces of code as well. It's impossible for us to diagnose what the problem is if we can't reproduce it ourselves.
We're not psychic.

It is a bit weird that it's looking for ALSA on Windows, but it shouldn't matter. All that's saying is that it failed to use ALSA for sound, which is fine.

Look. You want us to help you find the problem, right? Who knows, maybe it's a bug in Allegro we need to fix. But you have to help us do that by giving us code that we can run and that misbehaves for you. It's not that we do not want to help you otherwise, we just can't.

That said, do any of Allegro's examples show the same problem?

I can see the problem for you... no usefull code - no help...
So maybe I have to create a small app that uses my soundmanager.dll...

>> That said, do any of Allegro's examples show the same problem?

These examples are win apps in c++ with no .NET-connection...
All of these examples are easy but many things were did automatically, e.g. using standard-Stream feeders, creating stream from file (al_stream_from_file) and so on.... I'm not able to do it in this way, I have to use this stuff more deeper with using e.g. al_load_stream_wav.... there's to much auto in the samples.... but you have absolutely right.... without nice source code, nobody can help me accurately...

I have to consider my stuff and my questions for help...
Thanks till now...

Better would be just to take the code in that dll that uses allegro, and put it in a simple test program.

Ok, now I use my allegro stuff in a non .NET-App and my program doesn't want to quit as well in this _al_win_input_exit. For what is

WaitForSingleObject(ack_event, INFINITE);

waiting ?

And if nobody knows for what allegro is waiting for eternity, how can I debug this event stuff ? Is there an array or where can I find a reason to wait ?

I don't want to change allegro.... but finally I have to ... perhaps.
INFINITE -> 100 (ms)

Do the example which come with Allegro work?

I noticed that too. Happens sometimes and a switch in/out of debugger makes it continue. I didn't look into it yet, but I will.

>> Do the example which come with Allegro work?

Yes, they do...correctly

_al_win_input_init

and

_al_win_input_exit

without waiting at

WaitForSingleObject(ack_event, INFINITE);

Seems, that all the fancy / magic events are comming at the end and no one has to wait for something that nobody seems to know exactly :-(

>> Happens sometimes and a switch in/out of debugger makes it continue.

Do you mean that this is not happen if I compile in RELEASE or if I don't debug
with MSVC-IDE ?

Update:
Ok, I'm brassed off... my INFINITY takes 500ms now... and everything is fine...

I just happens sometimes, it's one of those bugs. You can't make a diagnosis just by looking at the symptoms.

> You can't make a diagnosis just by looking at the symptoms.

In principle - YES. But my question was, what is allegro at this point waiting for. Guess that this can't be all events in our universe, but some ending streaming stuff, special shut-down-allegro stuff and so on...

The function is described here: http://msdn.microsoft.com/en-us/library/ms687032.aspx

So basically, it waits for the event in the first parameter. For some reason, this event does not occur sometimes. To fix the problem, someone (who has Windows, so not me) has to figure out why this event does not occur.

It waits for input evens, it's perfectly clear what it does and how it should work, to me at least.

>> It waits for input evens,
>> it's perfectly clear what it does and how it should work, to me at least.

Ok, seems, that nobody understands, that I'm looking for the specific / the missing input event. I do know, what "WaitForSingleObject" does...

But that's the coolness of Open Source stuff.... if you don't know what there's going on -> change it !!

Not knowing what's going on was never a reason to change anything but your own knowledge. Not the code you don't understand.

Can't help you on this event stuff though. Because I don't know what it's about.
Just thought that the above statement was kind of irritating.

Actually, the WaitForSingleObject() you are referring to waits for the input thread to acknowledge that it ended, after it has been instructed to end with an APC. Looking at your logfile, the input thread didn't process the APC for some reason.
I can't reproduce this any more. The problem might be solved already in SVN, with the latest memory corruption fix in the input code.

You know what, that would make sense. A bug like that (that shouldn't be possible) could easily be caused by memory corruption.