fri0@tank.uchicago.edu (Christian E. Fritze) (02/13/90)
Dear Netters!
I'm a beginning Mac programmer trying to use the sound manager routines to play
some sampled sound. Why does the following code (an excerpt from my THINK C
4.0 program) break my Mac at the indicated function call? Odd address, says
the debugger; sound doesn't play. IMV says that passing a NIL pointer to
SndNewChannel tells SndNewChannel to allocate a channel for you and return it.
In fact, my code is almost identical to a Pascal sample I found on GEnie.
What's going on here?
=========================================================================
#include <SoundMgr.h>
#define NULL 0L
main()
{
SndChannelPtr soundPtr;
Handle soundHndl;
OsErr Check;
soundHndl = GetResource('snd ',16658);
/*This call does it... */
Check=SndNewChannel(&soundPtr,sampledSynth,initSRate22k,NULL);
SndPlay(&soundPtr,soundHndl,TRUE);
SndDisposeChannel(&soundPtr,FALSE);
DisposPtr(soundPtr);
DisposHandle(soundHndl);
}
Thanks for any help. Hope this isn't a really STUPID question.
(Running SE, 4MB, Sys 6.0.2)cs290ac@ux1.cso.uiuc.edu (02/13/90)
well, this might not be quite right, but here's what I think... When you pass pointers as variables, I don't think you need the &. This would pass a pointer to the pointer, and I think they just want the pointer. If the routine is expecting a pointer and gets a handle (when you pass it &pointer), it would screw everything up and you'd be likely to get an odd adress error (well, 50% likely anyways). If this is the case, your error would've come up before playing the sound (which would never play). hope that's the bug.. -Ron Smith
beard@ux1.lbl.gov (Patrick C Beard) (02/14/90)
In article <7605@tank.uchicago.edu> fri0@tank.uchicago.edu (Christian E. Fritze) writes:
#
#Dear Netters!
#
#I'm a beginning Mac programmer trying to use the sound manager routines to play
#some sampled sound. Why does the following code (an excerpt from my THINK C
#4.0 program) break my Mac at the indicated function call? Odd address, says
#the debugger; sound doesn't play. IMV says that passing a NIL pointer to
#SndNewChannel tells SndNewChannel to allocate a channel for you and return it.
##include <SoundMgr.h>
##define NULL 0L
#
#main()
#
#{
#
#SndChannelPtr soundPtr;
#Handle soundHndl;
#OsErr Check;
#
#soundHndl = GetResource('snd ',16658);
#
# /*This call does it... */
#Check=SndNewChannel(&soundPtr,sampledSynth,initSRate22k,NULL);
As you said, IMV says that passing a NIL pointer gets you a new channel.
You forgot to initialize the variable soundPtr to nil! Therefore, you
get a crash when SndNewChannel gets whatever happens to be on the stack.
I won't comment on the "stupidity" of this question. Apple, why did
you come up with such a bizarre way to allocate a channel? I much
prefer the NewWindow method. In other words, we can preallocate memory
for Windows and pass it to NewWindow:
WindowPtr myWindow = (WindowPtr)NewPtr(sizeof(WindowRecord));
WindowPtr w = NewWindow(myWindow, bounds, title, visible, procID,
behind, goAwayFlag, refCon);
I suppose the rationale was that an OSErr code should be returned
because opening a channel does more than allocate memory for the
channel record, but perhaps a SoundError() function would be better.
-------------------------------------------------------------------------------
- Patrick Beard, Macintosh Programmer (beard@lbl.gov) -
- Berkeley Systems, Inc. ".......<dead air>.......Good day!" - Paul Harvey -
-------------------------------------------------------------------------------