| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 473.1 | | BGSDEV::MORRIS | Tom Morris - Light & Sound Engineering | Mon Mar 03 1997 19:51 | 17 |
| It's impossible to guess what the problem is from the
brief description, but I'd hazard a guess that the problem
is with the program, not waveOutClose.
We've got plenty of programs that call it without problem
and the examples that I've compiled off the SDK appear
to work fine (try 'reverse' for example).
Some things to look for:
- does the sound play?
- are all the messages passed to the callback
window/function getting posted and processed correctly?
- does doing a waveOutReset before the close help at all?
- do you have a race someplace among multiple threads?
Tom
|
| 473.2 | more detail | ALLOUT::STEWART | Bob Stewart | Tue Mar 18 1997 11:22 | 31 |
| >
Some things to look for:
- does the sound play?
********** yes
- are all the messages passed to the callback
window/function getting posted and processed correctly?
********** I think so, I looked, in particular the code gets here
because of a DONE message. That was what I first thought was the cause
of the hang, but the message arrives.
- does doing a waveOutReset before the close help at all?
********** Haven't tried that yet.
- do you have a race someplace among multiple threads?
********** What multiple threads? This program is fairly simple, it
doesn't even do double buffering.
>
So, do you mean "It is expected behavior that execution can go into
waveOutClose and never come out." ??? How could the program cause that?
I thought waveOutClose was supposed to return with an error if it
didn't like something.
|
| 473.3 | works on intel | ALLOUT::STEWART | Bob Stewart | Mon Mar 24 1997 14:49 | 2 |
| The program runs fine on Intel Windows95 VC++ 4 Standard Edition...
|
| 473.4 | sorry, no good suggestions | DECWET::PETERSON | | Mon Mar 24 1997 20:25 | 16 |
| to debug it, you might try catching all exceptions in the debugger just
before you call waveOutClose
to do it, select exceptions in the debug menu, and then select all
exceptions, set them to debugger catch always, and then select change
before you exit. when you hit an exception, type go and the debugger
will prompt you whether you want user handlers to handle it (answer
yes).
you might also try the VC++ V5.0 kit. it might be better (although it
requires NT 4.0)
what version of NT are you running, and does it run on Intel Windows NT
as well as Windows 95?
this doesn't sound like a compiler issue, so you might have better luck
asking in thedecwet:: nt-developer conference or in the humane:visualc
conference.
|
| 473.5 | fails with Intel NT too, works with 95 | ALLOUT::STEWART | Bob Stewart | Tue Apr 08 1997 08:55 | 12 |
| The program also fails with the same external symptoms on Intel NT 4.0
with VC++ 5.0. So I guess it is an NT bug not an Alpha bug, and is not
fixed by C++ 5.
My current GUESS is that the wave close routine thinks that the buffer
has not been released, and is waiting for it instead of returning an
error, but I don't really know.
If anyone wants to try it, it is on the CD from the book "Visual C++ 4
Masterclass" from WROX press. The program name is Wavescope. Build it,
start it, find a WAV file, play it, then try to close the program.
|
| 473.6 | reset no help, no exceptions either | ALLOUT::STEWART | Bob Stewart | Tue Apr 08 1997 13:36 | 4 |
| waveOutReset does not help, it just hangs in reset instead of in close
The debugger does not report any exceptions.
|