Another weird sound problem
John Stiles
OK, thanks to the numerous replies of the members of c.s.m.p.g, I've got
my sound code working great!
Almost. It crashes PowerBook 5300's consistently. For some reason, it
works on all desktop Power Macs but I've had lots of users saying their
5300 dies instantly when they open up the application.
Here's my current sound code. Much abbreviated of course, because the
algorithm isn't important in this case (is it?). FWIW, this code worked
when I used the SndPlayDoubleBuffer technique, but I don't know if it
worked quite as fluidly.
SndCommand command;
void InitSound( void )
{
SndCallBackUPP callBackUPP = NewSndCallBackProc( SoundCallBack );
SndNewChannel( &sndChannel, sampledSynth, initMono, callBackUPP );
sndHeader = (SoundHeaderPtr) NewPtrClear( sizeof( SoundHeader ) +
SOUND_BUFSIZE );
sndHeader->samplePtr = nil;
sndHeader->length = SOUND_BUFSIZE;
sndHeader->sampleRate = SoundRate << 16;
sndHeader->baseFrequency = kMiddleC;
command.cmd = callBackCmd;
command.param1 = 0;
command.param2 = (long)LMGetCurrentA5();
SoundCallBack( sndChannel, &command ); // start the ball rolling
}
pascal void SoundCallBack( SndChannelPtr chan, SndCommand *command )
{
int i;
SndCommand myCommand;
long myA5 = SetA5( command->param2 ); // set up A5 world
if( soundIsOn )
{
// sndHeader->sampleArea[i] = stuff;
// fill up the sound buffer here
}
else
{
memset( sndHeader->sampleArea, 0x80, SOUND_BUFSIZE );
}
sndHeader->sampleRate = SoundRate << 16; // <-- the soundrate can
change dynamically
myCommand.cmd = bufferCmd;
myCommand.param1 = 0;
myCommand.param2 = (long) sndHeader;
SndDoImmediate( chan, &myCommand ); // buffer the sound
SndDoCommand( chan, command, true ); // callback again
SetA5( myA5 ); // close up A5 world
}
Note the SndDoCommand a few lines up. It is calling itself back once
again. Therefore the sound should loop continuously.
Any ideas, folks? Did I make any obviously dumb blunders?
*Stiles
Jackson Software Development
In article <jstiles-0710...@105.0.102.32.128.in-addr.arpa> John
Stiles, jst...@uclink4.berkeley.edu writes:
>Note the SndDoCommand a few lines up. It is calling itself back once
>again. Therefore the sound should loop continuously.
I had a similar problem that only showed up when Quicktime was installed.
I fixed it by not actually calling SndDoCommand in the callback routine,
but
instead setting a variable in the callback and then checking the variable
in
my event loop and restarting the sound there. As long as the loop was
greater than about 50 milliseconds it worked without clicking.
I have read that SndDoCommand can be called at interrupt time depending
on the command, and that the bufferCmd was one of those commands, but
it didn't work for me when Quicktime was installed.
Darrin
Jim Reekes
In article <jstiles-0810...@105.0.102.32.128.in-addr.arpa>,
jst...@uclink4.berkeley.edu (John Stiles) wrote:
> In article <53dnv9$2...@kirin.wwa.com>, Jackson Software Development
> Oh... great!! This is news to me. Oh well. I am not sure how well this
> technique will work in my code--I am currently generating about 10ms of
> sound at a time--but I can hack it out.
I use the same basic code as you. Mine has never crashed. QuickTime uses
the same idea as well. It doesn't crash either. The only thing I noticed
was that you never initialized your sndChannel to nil (and don't allocate
your own).
> Thanks. I guess THIS is why SndPlayDoubleBuffer is important...!
No, SndPlayDoubleBuffer() is only important for one reason. It was
designed for SndStartFilePlay(). Other than that, the bufferCmd and
callBackCmd sequence are the same. The later provides more control and
flexibility. Both internally use the same code to play the sound, and
therefore neither are more effecient.
--
Jim Reekes, Polterzeitgeist | QuickTime Products R&D
| Sound Manager Expert
Apple Computer, Inc. | "All opinions expressed are mine, and
2 Infinite Loop MS 302-3KS | do not necessarily represent those
Cupertino, CA 95014 | of my employer, Apple Computer Inc."
Norman Franke
In article <jstiles-0710...@105.0.102.32.128.in-addr.arpa>,
jst...@uclink4.berkeley.edu (John Stiles) wrote:
> Almost. It crashes PowerBook 5300's consistently. For some reason, it
> works on all desktop Power Macs but I've had lots of users saying their
> 5300 dies instantly when they open up the application.
> pascal void SoundCallBack( SndChannelPtr chan, SndCommand *command )
> {
> sndHeader->sampleRate = SoundRate << 16; // <-- the soundrate can
> change dynamically
> }
I think this is your problem. You can only call SndDoImmediate or
SndDoCommand with commands that do not move memory. Changing the sampling
rate can cause memory movement and allocation as it opens components to
perform sample rate conversion. If you want to change any parameters, I'd
recommend some other method.
--
Norman Franke
fra...@llnl.gov
John Stiles
In article <53dnv9$2...@kirin.wwa.com>, Jackson Software Development
<devel...@jacksoncorp.com> wrote:
> In article <jstiles-0710...@105.0.102.32.128.in-addr.arpa> John
> Stiles, jst...@uclink4.berkeley.edu writes:
> >Note the SndDoCommand a few lines up. It is calling itself back once
> >again. Therefore the sound should loop continuously.
>
> I had a similar problem that only showed up when Quicktime was installed.
> I fixed it by not actually calling SndDoCommand in the callback routine,
> but
> instead setting a variable in the callback and then checking the variable
> in
> my event loop and restarting the sound there. As long as the loop was
> greater than about 50 milliseconds it worked without clicking.
>
> I have read that SndDoCommand can be called at interrupt time depending
> on the command, and that the bufferCmd was one of those commands, but
> it didn't work for me when Quicktime was installed.
Oh... great!! This is news to me. Oh well. I am not sure how well this
technique will work in my code--I am currently generating about 10ms of
sound at a time--but I can hack it out.
Thanks. I guess THIS is why SndPlayDoubleBuffer is important...!
*Stiles
.
.
.
.
.
.
.
.
.
.
.
.
...... trying to confound his stupid NNTP server
John Stiles
First off... wow!! Jim Reekes! I am talking to God. Jim, the new Sound
Manager is awesome, just so you know. Never thought I'd get a reply from
the author of the Sound Manager himself...!
> > Oh... great!! This is news to me. Oh well. I am not sure how well this
> > technique will work in my code--I am currently generating about 10ms of
> > sound at a time--but I can hack it out.
> I use the same basic code as you. Mine has never crashed. QuickTime uses
> the same idea as well. It doesn't crash either. The only thing I noticed
> was that you never initialized your sndChannel to nil (and don't allocate
> your own).
Actually, I was doing this when I was defining the sndChannel
(SndChannelPtr sndChannel = nil;). But that didn't seem to be the cause at
all.
One thing I noticed, but I am unsure if it is the problem, was that I was
defining the callback function as:
pascal void SoundCallBack( SndChannelPtr chan, SndCommand *command )
Shouldn't it be:
pascal void SoundCallBack( SndChannelPtr chan, SndCommand command )
...?
However, I did rewrite it this way, but it didn't seem to have any major
effect on the program on my Mac at all. This might fix the PowerBook
problem, but I'm not sure about that, because I don't have a test
PowerBook to work with. (Isn't that just a pain?!)
> > Thanks. I guess THIS is why SndPlayDoubleBuffer is important...!
> No, SndPlayDoubleBuffer() is only important for one reason. It was
> designed for SndStartFilePlay(). Other than that, the bufferCmd and
> callBackCmd sequence are the same. The later provides more control and
> flexibility. Both internally use the same code to play the sound, and
> therefore neither are more effecient.
Oops. Guess I did a little extra work then, because I just re-implemented
my old SndPlayDoubleBuffer solution. I mean, it worked, right? And now, to
handle a possible change in SoundRate, the code simply disposes the sound
channel whenever the rate changes and makes a new one. Simple, and
inefficient, but the SoundRate will never change unless the user opens up
a customization dialog anyway (thereby doing something like
SndDisposeChannel/SndNewChannel won't cause a speed hit).
Say, though, I have one big Sound Manager question for you. If I turn on
Virtual Memory, the sound code I have listed above starts to sound awful!
The sound latency is quite unacceptable. It is as if it were buffering
several times in a row rather than just once. You see, the code is
actually a square wave generator, and the frequency and volume variables
change over time. But the changes are choppy and rough when Virtual Memory
is on, yet clean and smooth when VM is off. I have done a million
different things to avoid it, so I have to conclude that it's a Sound
Manager bug (or hidden feature). Help!
(As a side note, the entire reason I ever bothered to implement this
gosh-darn callback code which I just ripped out was to try to avoid this
bug/hidden feature, but it didn't fix the problem at all!)
*Stiles
Jim Reekes
In article <jstiles-0810...@105.0.102.32.128.in-addr.arpa>,
jst...@uclink4.berkeley.edu (John Stiles) wrote:
> Say, though, I have one big Sound Manager question for you. If I turn on
> Virtual Memory, the sound code I have listed above starts to sound awful!
> The sound latency is quite unacceptable. It is as if it were buffering
> several times in a row rather than just once. You see, the code is
> actually a square wave generator, and the frequency and volume variables
> change over time. But the changes are choppy and rough when Virtual Memory
> is on, yet clean and smooth when VM is off. I have done a million
> different things to avoid it, so I have to conclude that it's a Sound
> Manager bug (or hidden feature). Help!
Uh huh. So don't turn on VM. It's not a Sound Mgr bug. It's just a
conflict of interest between real time services and VM.
> (As a side note, the entire reason I ever bothered to implement this
> gosh-darn callback code which I just ripped out was to try to avoid this
> bug/hidden feature, but it didn't fix the problem at all!)
Yeah, life as a programmer!
Jim
John Stiles
In article <reekes-0910...@reekji.apple.com>, ree...@apple.com
(Jim Reekes) wrote:
> In article <jstiles-0810...@105.0.102.32.128.in-addr.arpa>,
> jst...@uclink4.berkeley.edu (John Stiles) wrote:
>
> > Say, though, I have one big Sound Manager question for you. If I turn on
> > Virtual Memory, the sound code I have listed above starts to sound awful!
> > The sound latency is quite unacceptable. It is as if it were buffering
> > several times in a row rather than just once. You see, the code is
> > actually a square wave generator, and the frequency and volume variables
> > change over time. But the changes are choppy and rough when Virtual Memory
> > is on, yet clean and smooth when VM is off. I have done a million
> > different things to avoid it, so I have to conclude that it's a Sound
> > Manager bug (or hidden feature). Help!
> Uh huh. So don't turn on VM. It's not a Sound Mgr bug. It's just a
> conflict of interest between real time services and VM.
Oh, come on, great answer!! I don't use VM as a rule--32MB is quite
enough, thanks--but I have many users that do use VM. There's got to be a
way to make it smoother than this! And if you try to tell me that's a
feature, I'll laugh *really* hard.
True, I know, it's hard to call a routine 100 times per second when you're
paging in and out from the hard disk. But I don't think that's an
acceptable excuse for this Sound Manager behaviour. And FWIW, I can run
the program with 33MB of virtual memory (on a 32MB system) with system
memory not even 50% full, and the same problem surfaces.
I'd really like to be able to run my system at a 33MB virtual memory
setting, actually, so I can take advantage of the reduced application
footprint this provides. But this is the main reason that I can't!
> > (As a side note, the entire reason I ever bothered to implement this
> > gosh-darn callback code which I just ripped out was to try to avoid this
> > bug/hidden feature, but it didn't fix the problem at all!)
> Yeah, life as a programmer!
OK, OK, I know it sucks. But there must be a way around this blatant flaw,
and if anyone knows it, it's you. So really, what's the secret?!?
*Stiles
Jim Reekes
In article <jstiles-0910...@105.0.102.32.128.in-addr.arpa>,
jst...@uclink4.berkeley.edu (John Stiles) wrote:
> In article <reekes-0910...@reekji.apple.com>, ree...@apple.com
> (Jim Reekes) wrote:
>
> > Uh huh. So don't turn on VM. It's not a Sound Mgr bug. It's just a
> > conflict of interest between real time services and VM.
>
> Oh, come on, great answer!! I don't use VM as a rule--32MB is quite
> enough, thanks--but I have many users that do use VM. There's got to be a
> way to make it smoother than this! And if you try to tell me that's a
> feature, I'll laugh *really* hard.
>
> True, I know, it's hard to call a routine 100 times per second when you're
> paging in and out from the hard disk. But I don't think that's an
> acceptable excuse for this Sound Manager behaviour. And FWIW, I can run
> the program with 33MB of virtual memory (on a 32MB system) with system
> memory not even 50% full, and the same problem surfaces.
>
> I'd really like to be able to run my system at a 33MB virtual memory
> setting, actually, so I can take advantage of the reduced application
> footprint this provides. But this is the main reason that I can't!
I'm not going into this one, again. I'll give you this simple clue. You
cannot page during a sound hardware interrupt. Therefore I must defer the
actual function until a time that paging is safe, using the call
DeferUserFn() to VM. VM then owns this function and will call it when it
decides it's safe. This happens at some time later, when all SCSI activity
is clear. At this point in time the hardware interrupt handler calls into
the Sound Mgr for more data to satisfy the hardware request. It's exactly
like I had said, "It's not a Sound Mgr bug. It's just a conflict of
interest between real time services and VM." If you'll have noticed, you
cannot use QuickTime and VM either. For one thing, the SCSI bus is really
busy while trying to play a movie and therefore sound is held off for
longer periods of time.
John Stiles
> I'm not going into this one, again. I'll give you this simple clue. You
> cannot page during a sound hardware interrupt. Therefore I must defer the
> actual function until a time that paging is safe, using the call
> DeferUserFn() to VM. VM then owns this function and will call it when it
> decides it's safe. This happens at some time later, when all SCSI activity
> is clear. At this point in time the hardware interrupt handler calls into
> the Sound Mgr for more data to satisfy the hardware request. It's exactly
> like I had said, "It's not a Sound Mgr bug. It's just a conflict of
> interest between real time services and VM." If you'll have noticed, you
> cannot use QuickTime and VM either. For one thing, the SCSI bus is really
> busy while trying to play a movie and therefore sound is held off for
> longer periods of time.
OK, I wasn't fully clear on the issue. I guess nothing can be done without
rewriting Virtual Memory. Well, hopefully this doesn't mean Copland will
maul my sound code. Thanks for replying, at least, and clarifying the
issue.
Now if only there was a way to get VM to call the function more often...
but that's not your department and I know it!...
*Stiles
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..... who hates the campus NNTP server that forces him to waste this space
Al Evans
In article <reekes-1010...@reekji.apple.com>,
Jim Reekes <ree...@apple.com> wrote:
>It's exactly
>like I had said, "It's not a Sound Mgr bug. It's just a conflict of
>interest between real time services and VM."
No, Jim. It's a conflict of interest between real time services and VM
*IN THE MACOS*. And the same kind of comment goes for your response in
another thread, which was along the lines of "your problem is caused
by the sound-hardware buffer size, about which I can do nothing."
A counter-example: I can crank up enough movies on my BeBox to start
VM thrashing. Within a couple of seconds, it will settle down to play
them ALL, with reasonable performance, hitting the disk continuously.
The conflict of interest is not inherent, it is due to the failure of
Apple to redesign their operating system. And -- perhaps unfortunately --
since you're a well-known Apple representative, your implication that
these deficiencies are just "facts of life" will be widely perceived
as indicating Apple's continued unwillingness or inability to do
anything about them.
It seems to me that you guys should at least cop a line from Metrowerks:
"Apple Computer apologizes for the inconvenience."
Not quite ready to start expecting less from Apple....
--Al Evans--
--
|||| Al Evans -- a...@powertools.com -- proud of Graphic Elements Release 3 ||||
==== A new standard for high-performance interactive Macintosh graphics ====
==== Available from mac.archive.umich.edu and mirrors in ====
|||| /mac/development/libraries/graphicelements3.0.sit.hqx ||||