views:

371

answers:

4

I've got a following situation. On a machine there is a Fritz ISDN card. There is a process that is responsible for playing a certain wave file on this device's wave out (ISDN connection is made at startup and made persistent). The scenario is easy, whenever needed the process calls waveOutWrite() on the previously opened wave device (everything initialized without any problems of course) and a callback function waits for MMWOMDONE msg to know that the playback has been finished.

Since a few days however (nothing changed neither in the process nor the machine) the MMWOMDONE message comes immediately after calling waveOutWrite() even though the wave lasts a couple of seconds. Again no error is reported, it looks like the file was played but had zero length (which is not the case). I am also sure that waveOutReset() was not called by my process (it would also trigger sending the mentioned message). I already used to have some strange problems in the past that where solved simply by reinstalling TAPI drivers. This time for some reason it is problematic form me to perform that once again and am trying more analytical approach :). Any suggestions what might cause such a behavior? Maybe sth on the other end of the ISDN line?

+2  A: 

I don't have the time to Google too much for this, but I know that either Larry Osterman or Raymond Chen blogged about a similar situation.

I'll check back later when I have more time to see if this question is still open.

Stu
http://blogs.msdn.com/larryosterman/archive/2009/02/19/playsound-xxx-snd-memory-snd-async-is-almost-always-a-bad-idea.aspx
Billy ONeal
A: 

What is the return value when the sound does not play? If you get MMSYSERR_NOERROR that points to the driver incorrectly reporting to the OS that the buffer was processed.

Has the WAV file itself changed? This blog entry indicates that some pretty in-depth validation is done on the metadata.

Aidan Ryan
A: 

What is the return value when the sound does not play? If you get MMSYSERR_NOERROR that points to the driver incorrectly reporting to the OS that the buffer was processed.

If I got an error result everything would be easier :). Unfortunately I get MMSYSERR_NOERROR. The wavefile is generated every time, but the way it happens has not changed. So it really looks like for some reason the system reports wrong, or does not report everything. I will try to take a closer look at the generated file.

I don't have the time to Google too much for this, but I know that either Larry Osterman or Raymond Chen blogged about a similar situation.

I went thorugh Larry's and Raymond's blogs but didn't find anything helpful. Only some Larry's posts explaining how to use wave output. This however haven't helped to solve the issue.

TyBoer
You should avoid posting answers like this unless you have genuinely solved the problem. These responses belong in comments. For the record, Larry Osterman's post on this is : http://blogs.msdn.com/larryosterman/archive/2009/02/19/playsound-xxx-snd-memory-snd-async-is-almost-always-a-bad-idea.aspx
Billy ONeal
+3  A: 

Based on your description, you are doing the playing asynchonously. Are you sure that the backing memory for the wav file is not being cleaned up in that time?

Jack Bolding