Xbox LIVE Indie Games
Sort Discussions: Previous Discussion Next Discussion
Page 1 of 1 (10 posts)

InstancePlayLimitException was unhandled??

Last post 5/5/2007 12:33 AM by Adam and Perusse. 9 replies.
  • 4/11/2007 12:04 PM

    InstancePlayLimitException was unhandled??

    When executing the following code I sometimes get the error posted in the subject line.

    engineCue = soundBank.GetCue(EngineSound);
    if (engineCue != null)
    {
        if (!engineCue.IsDisposed)
        {
            engineCue.Play();
        }
    }

    Any ideas on why it is throwing an exception?
     

  • 4/11/2007 12:15 PM In reply to

    Re: InstancePlayLimitException was unhandled??

    Based on the exception name, it sounds like too many instances of this sound are playing.  I haven't worked with xact yet, but is there a way to tell if a sound is currently playing, and if so how many instances of the sound, to avoid the problem you are experiencing?
  • 4/11/2007 2:37 PM In reply to

    Re: InstancePlayLimitException was unhandled??

    pfo is right ... what you probably want to do is change the behavior in xact so that when the instance limit is reached/exceeded, it will either queue, or just ignore the extra requests.
  • 4/19/2007 3:49 PM In reply to

    Re: InstancePlayLimitException was unhandled??

    Oddly if you set the Cue to only play a limited amount of instances of the sound and tell it to "Fail to Play" any more it will cause an exeception. Apparently the key word hear is "Fail". I would choose "Replace" as this ends one of the other instances and plays this one. "Queue" is pretty useless as it will play when one of the others end so it won't play when it is supposed to and your sound will be out of sync with the game.

    Personally I would have liked an ignore request option.

  • 4/27/2007 2:56 PM In reply to

    Re: InstancePlayLimitException was unhandled??

    I just got bit my this one myself, thanks Joel for working this one out.

    However throwing an excpetion in this case seems to defeat the whole purpose of XACT. In the XACT world a sound designer makes decisions about what sounds to play, when and how loud etc. So if the sound designer has determined that there should be a limit and the result is FailToPlay then why should the developer have to worry about this. By all means give a return value if its something that some developers want to know about but throwing an exception seems pretty heavy handed. It means that we have to potentially wrap every single Play call in a handler just in case this happens - or change the limits to no limits for every sound effect.

  • 4/27/2007 3:07 PM In reply to

    Re: InstancePlayLimitException was unhandled??

    Yeah I came up against this too. I just put the offending code in a try-catch... its irritating... but is catching exceptions like that on a frequent basis going to effect performance?
  • 4/27/2007 3:11 PM In reply to

    Re: InstancePlayLimitException was unhandled??

    The performance impact should be minor, but this is probably still a mistake in the framework.

    Could someone open a bug on this over on the connect website, please? (that way it gets prioritised higher than if I just enter it internally, since it will be marked as an issue that real customers have actually run into)
  • 4/27/2007 3:12 PM In reply to

    Re: InstancePlayLimitException was unhandled??

    Done...
  • 4/27/2007 3:18 PM In reply to

    Re: InstancePlayLimitException was unhandled??

  • 5/5/2007 12:33 AM In reply to

    Re: InstancePlayLimitException was unhandled??

    In my case, I'd really need to be able to ignore the new sound instances, so I added a try-catch, but my output is spammed with:

    A first chance exception of type 'Microsoft.Xna.Framework.Audio.InstancePlayLimitException' occurred in Microsoft.Xna.Framework.dll

    Any solution? This is very annoying!

    P.S. : Finally, I decided to create my own "one instance limit" and set LimitInstances to false in XACT. No more first-chance exceptions. Of course, I hope Microsoft will fix "FailToPlay" so that it doesn't throw exceptions, or at least add a new choice...

Page 1 of 1 (10 posts) Previous Discussion Next Discussion