static callbacks in a class

[Gyannea]

I have a class which has a static callback function to receive messages from 'waveOutxx()' sound card handling functions. What happens if an instance of the class is created (via "new") and then deleted, but a stray MM_WOM_xx message remains in the Window's message queue? Does the static callback function still exist?

I am having some type of problem deleting a class instance. THe instance is deleted but attempts to use "new" in another class instance after the fact crash the system (Windows exits the program) and the heap appears to be okay. This problem does not happen if I do not delete the aforementioned instance.

I beleive the problem has something to do with being able to completely rid the system of the previous class instance which contain independent threads and static callback functions.

[galathaea]

Static functions exist for the lifetime of the program and are not tied to any instance of the class. So I would guess the problem is occuring elsewhere in the code and possible conflicting attempts to grab the resources. This sounds like a textbook design problem whose solution would include the use of a singleton class, but I couldn't be sure unless I had a better view of which class were participating in instancing and initializing the device resources.

[ovidiucucu]

A static member function does not need a class instance to be called,
i.e. a call such CClass::AStaticFunction() can be done
without create an object of CClass type.

To protect a section of code from being accessed by more than one thread,
use synchronization objects, e.g. critical section.

[Gyannea]

I guess this is what I get for trying to encapsulate a callback function. In order to be of any use, the static callback function uses a passed parameter to call the method appropriate to the instance.

Now if the instance is deleted and a message for the static callback function remains, its not clear what will happen.


The callback is for handling messages sent by the soundcard hardware, and I am having difficulty properly closing the soundcard hardware. Calls to
waveOutReset() and waveOutClose()
never return and I don't know why. If I don't use them I can then call the unprepare header API function and everything seems okay until I delete the instance. Then problems come later. If I do not delete the instance, the problems do not arise.

I have placed Critical Section protection in the threads, but it doesn't seem to help. I am not sure what a singleton class is.

I probably should chuck the entire encapsulation effort. Windows callback functions simply are not designed for that.

Now to figure out the mystery of the waveOutxx closing functions!

[JamesSchumacher]

inside the callback? Calling other wave functions inside a callback function can cause deadlock.

See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/mmfunc_8zdv.asp

Or did I misunderstand and the callback you are talking about is a thread, in which this wouldn't apply.

[Gyannea]

Well, I thought it was shielded from being inside a callback since I pass a parameter which is a pointer to the class instance. Thus inside the callback function I have a line like:

transmitter->HandleWaveOutput();

where 'transmitter' points to this instance of the object. The function it calls is a class member function but that appears to be insufficient. I get away with calling 'waveOutWrite()' in the member function but any subsequent call to 'waveOutClose()' or 'waveOutReset()' locks the program.

I found a tutorial on a website that had the first and only explanation I have seen as to how the waveOutxx functions actually work under the hood. Still lots of mysteries, but that really helped. The website also gave the

loop:
waveOutPrepareHeader()
waveOutWrite()
waveOutUnprepareHeader()
Fill buffer
end loop

approach. I don't see this in Petzold or any other source I have looked at. However, Creative Labs did it in an example program for the Soundblaster and it is mentioned in the SDK that came with WATCOM for the waveInxx functions (but not the waveOutxx). I DON'T use the Unprepare in the loop and recording and playback still work. I have added it and it appears to make no difference. So it is still an unsolved mystery. What do these functions do?!? The down side of black boxes.

I am going to have to rethink the whole process. First and foremost it seeems the best thing to do is to ditch the encapsulation! Its a nice excercize in OOP but this is a real time problem and object oriented techniques and their overhead are not good approaches!

[JamesSchumacher]

calling that member function given the pointer to the object inside the callback, then yes you are calling the function within the callback.

[Gyannea]

Seems pretty obvious in hindsight. And if 'waveOutWrite()' had locked up then there would have been no question about it. But it works and so my transmission (playback) actually functions, but I am getting strange errors and it is undoubtedly due to this problem.

Redesign time!