Re: Calling waveOut functions from Visual C++ 2005?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

you do have to be very careful with who is calling which of those functions.
there are bad things that happen for instance if your callback function
tries to do a reset or to send a new header or some of the other functions.
you may want to cut down the code and post some of it here... and maybe also
ask on a .net developer group, there may be some quirks with .net using mm
functions that way.


"Chris P. [MVP]" <msdn@xxxxxxxxxxxx> wrote in message
news:174a6qaq5naln.1ombbhqt36vqb.dlg@xxxxxxxxxxxxx
On Mon, 15 May 2006 05:21:02 -0700, David Harrison wrote:

I have a Visual C++ application (2005 Express Edition). I want to call
the
waveform audio interface functions such as waveOutOpen,
waveOutPrepareHeader
etc. to play, pause and otherwise manipulate a block of audio wave
samples.

I also have the Platform SDK installed, so I have tried two methods:
1) Calling the functions directly (linking with WinMM.lib and including
the
mmreg.h etc include files).
2) Using the .NET platfom Invoke, using the
System::Runtime::Interopservices
DLLImport attribute to declare a .NET wrapper around the native C
functions.

Either way works, up to a point. The problem is that when the wave file
stops playing, either by reaching the end, or when I call the
waveOutReset
function, the application aborts. When using the debugger, I simply get
a
message that says error in kernel32.dll, so I cannot find the problem.

I am allocating memory for the wave samples using the C native malloc
function. I am not using GlobalAlloc or any of the other fancy memory
allocation functions.

Should I Be?

Does anyone have any idea why a relatively simple set of functions are
not
working properly in Visual C++ 2005?

It sounds pretty standard, nothing is jumping out at me. Memory alloced
by
malloc is fine, the prepare header function locks the buffer in memory for
access by the driver (on Win2K/XP I think this is a NOOP).

Usually when apps just abort like this it's due to bad pointers being
passed to kernel functions or an attempt to move the instruction to 0.

--
http://www.chrisnet.net/code.htm
http://www.avdevforum.com/AV


.

Relevant Pages

  • Re: Memory Cleanup
    ... Calling GC.Collect is not the ... // The total memory has not gone down. ... reference counters, and nothing happens when objects go out of scope. ... objects just remain in memory waiting for the garbage collector to remove ...
    (microsoft.public.dotnet.languages.csharp)
  • exe$alononpage and exe$deanopgdsiz
    ... you can when it comes to calling these services. ... exe$deanonpgdsiz desides that the size of the deallocation is such that it ... Does the memory layout have to follow a convention? ... As these routines raise IPL, I assume that you have to be in Kernel mode ...
    (comp.os.vms)
  • Re: DataSet wont release memory?
    ... > Calling CG.Collect is ill advised in most situations, ... > that much memory, it seems like that isn't being referenced anymore. ... ds is a local object, and none of it's memory is being ... Yes, it's very fishy... ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Low memory errors with sp_xml_preparedocument
    ... not calling the sp_xml_removedocument since there are no ... active in SQLXML and what it is doing with the memory? ... >> shred XML documents which are initially held in a text ... >> The process will then fail every time it is called. ...
    (microsoft.public.sqlserver.xml)
  • Re: DataSet wont release memory?
    ... >> Calling CG.Collect is ill advised in most situations, ... >> that much memory, it seems like that isn't being referenced anymore. ... Only once per query... ... you'd be killing your ram in most circumstances. ...
    (microsoft.public.dotnet.framework.adonet)