• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Completing a sound before continuing on
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Completing a sound before continuing on


  • Subject: Re: Completing a sound before continuing on
  • From: Don Yacktman <email@hidden>
  • Date: Sun, 17 Apr 2005 12:14:04 -0600


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


  • Follow-Ups:
    • Re: Completing a sound before continuing on
      • From: Gen Kiyooka <email@hidden>
References: 
 >Completing a sound before continuing on (From: Chad Armstrong <email@hidden>)
 >Re: Completing a sound before continuing on (From: Sherm Pendley <email@hidden>)

  • Prev by Date: Re: Getting list-size (16 x 16) document icon for list
  • Next by Date: Re: Completing a sound before continuing on
  • Previous by thread: Re: Completing a sound before continuing on
  • Next by thread: Re: Completing a sound before continuing on
  • Index(es):
    • Date
    • Thread