Re: Completing a sound before continuing on
Re: Completing a sound before continuing on
- Subject: Re: Completing a sound before continuing on
- From: Gen Kiyooka <email@hidden>
- Date: Sun, 17 Apr 2005 11:30:25 -0700
You might try the Carbon SysBeep(0) call. I think it blocks, waiting
for the
command to complete before returning. Seems a lot simpler for beeping
than
the other solns.
Gen
On Apr 17, 2005, at 11:14 AM, Don Yacktman wrote:
On Apr 16, 2005, at 9:39 PM, Sherm Pendley wrote:
On Apr 16, 2005, at 10:44 PM, Chad Armstrong wrote:
I have a program which calls NSBeep() and then it closes the
program. I've found that if the default beep is a longer "beep"
sound, it will not always play the entire sound before the program
closes. Is there a way to have the program wait for the sound to
play in its entirety before quitting?
I don't know of one.
Read on for my way of hacking around this...
Also if I want to play an AIFF sound (not with NSBeep, but with
other methods), will I also have the same problem that the sound
would not finish before the program quit?
If you use NSSound, you could either repeatedly call -isPlaying in a
loop, or implement -sound:didFinishPlaying: in a delegate object.
I implemented something like what Chad wants for the illumineX games,
using NSSound. What I did is have the Quit menu item call a "preQuit"
method that would play the sound, order all the windows off the screen
(so that it doesn't feel like the app is slow to quit), and then
register a timer that would call the real "quit" in a few seconds --
long enough for the sound to finish playing, with a little extra time
to account for any delays in sound playback commencement.
Originally I tried polling -isPlaying in a loop, but that will lock up
your app, since NSSound needs you to return to the event loop
periodically -- it seems that it loads a sound playback buffer from
periodic timer calls, so if you don't return to the main event loop
then the sound will cut out when the buffer runs out, and yet the
NSSound will still think it is playing (so it creates a deadlock of
sorts). I suppose you could check and run the event loop in your
polling loop, but that's starting to get a bit obnoxious. I also
tried the NSSound delegate method, and that didn't work well at all.
In my experience, sometimes NSound calls it, and much of the time it
doesn't. It was very unreliable for me. (I haven't tested it lately
though, so it might be fixed by now. But if you need to deploy on
older versions of Mac OS X, this is a definite gotcha.) The only
thing that was stable was to estimate the length of the sound and have
a non-periodic timer fire after a long enough delay to let the sound
play out. When the timer fires, you finish with whatever it was that
you were doing. That works, even if it is a bit Rube Goldberg-esque.
Anyway, to see it in action, quit one of the illumineX games. Listen
and watch the dock icon closely and you can see (and hear) evidence of
the delay. ;-)
--
Later,
Don Yacktman
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden