Having looked at FACT.c I couldn't see anywhere that directly sets the stopped bit; I think it might be the case that when the notification is sent that the second cue starts playing, something consumes that event and maybe then thinks the first cue should be destroyed, and it's in the destroyed step that the stopped bit is set and the paused one is not cleared. I'm totally guessing though.

That actually might make some sense - we do have notifications and FNA does try to handle them:

https://github.com/FNA-XNA/FNA/blob/master/src/Audio/AudioEngine.cs#L374-L422

But it'd be weird to see different objects colliding on these events... it's hard to say.

When I sit down to test this the first thing I'll probably do is just breakpoint anywhere that the stop flag is set and see what might have triggered that, after that I'll monitor the events to see if something underneath is requesting a stop the application didn't ask for (Cue instance limits maybe?), from there hopefully I'll have enough to figure out what's up.

I think I found the issue - what happens on XNA when you call AudioEngine.Update() after calling b.Play()?

If you're able to change the XACT data, does adding a fade out time for the sound category fix it for FNA?

I'll need to try getting my XNA build setup working again; I think my VS licence is no longer valid. If you're able to point me towards any way of getting Ye Olde XNA Game Studio working on Windows 11, that'd be really helpful.

EDIT - oh, and thanks for looking into this!

Meant to look into this sooner but other stuff happened, will dump what I was able to find in the meantime:

The issue is the fadeout function I wrote, which assumes a tightly-packed stop event when a sound is destroyed (which is what happens when a Cue is destroyed for category limits and has a 0ms fade time):

• Instance limiter: https://github.com/FNA-XNA/FAudio/blob/master/src/FACT_internal.c#L722
• 0ms handler: https://github.com/FNA-XNA/FAudio/blob/master/src/FACT_internal.c#L946
• Cue state change: https://github.com/FNA-XNA/FAudio/blob/master/src/FACT_internal.c#L930-L938

Part of me wonders if this could be fixed by simply removing the 0ms handler and letting it be in STOPPING for exactly one frame, though I seem to have run into this problem before...

https://github.com/FNA-XNA/FAudio/blob/master/src/FACT_internal.c#L1691

... so it's one of those areas where it's a 1-frame inaccuracy, but I don't know if the frame step is in AudioEngine or in the XACT thread (both of which have their own update routines... sigh).

Thanks for your continued work, and sorry for not being able to keep up my end of the bargain my testing the XNA implementation. It's been a busy week with Christmas looming, and needing to deal with a tree that blew down! 😆

Argh - this all got rather complicated! The new change introduces a possible new issue (Stopping staying true indefinitely), fixes the original issue of a Cue ending up both Stopped and Paused, but neither of these occur if instance limits aren't exceeded.

I managed to open up the XACT project, and limit instances for the relevant category was ticked, with a limit of 1. ChatGPT thinks that in XNA 3.0 paused instances did not count towards the instance limit and that this changed in XNA 4.0 so that paused instances do count towards the limit. It couldn't provide a source though, so I don't know whether it's hallucinating.

If ChatGPT is correct the FAudio was nearly showing the correct behaviour originally - a paused Cue should contribute towards the limit, so presumably should be stopped and/or destroyed when another Cue from the same category is played. It's arguably a bug (see later!) prior to your PR that it remained in both IsPaused and IsStopped state. Resuming shouldn't work, because the Cue should have disappeared off into the ether once a second Cue is played.

FAudio appears to behave correctly both before and after the PR if instance limits are not exceeded.

FAudio appears to leave the IsStopping bit set indefinitely in the PR if instance limits are exceeded.

I've tried to summarise my findings below. The states are the values after the second Cue is played, and whether resumption works was tested manually (aurally?).

So, in summary:

• The pre-PR behaviour when instance limits are not exceeded is correct.
• The pre-PR behaviour of not-resuming when instance limits are exceeded is probably correct, but the Cue being both Paused and Stopped probably is not.
• The post-PR behaviour when instance limits are not exceeded is correct.
• The post-PR behaviour of not-resuming when instance limits are exceeded is probably correct, but the Cue remaining in an Stopping state indefinitely is probably not.

I hope that makes sense? One cup of tea was not enough to get through this 😁 I've pushed a commit to the repro-repo that might make investigating the indefinite IsStopping a little easier.

Epilogue

I feel a bit bad for taking up your time on what's basically an edge case - how FAudio should behave when a fool forgets that he's got instance limits set and chooses to exceed them. I've got my XNA 4.0 build setup working again now, so if it would be helpful for the project I could put some time into figuring out the reference implementation's behaviour in various scenarios?

Found the issue with the post-PR behavior, the engine wasn't updating the Cue because it was Paused, which is normally fine but the Stopping state should override that. Updated binaries will be here:

https://github.com/FNA-XNA/FAudio/actions/runs/12653809981

Thanks! I just tried the latest build, and assuming I've not made any silly mistakes, this goes back to the original issue of the Cue ending up both Paused and Stopped.

Was missing a bitflag in DestroySound, next batch of builds:

https://github.com/FNA-XNA/FAudio/actions/runs/12655539462

Splendid - with that latest build when the Cue is paused IsPaused and IsPlaying are true, and then as soon as the second Cue is played the first Cue transitions to IsStopped being true and IsPaused and IsPlaying being false. That sounds about right, so I think we can consider the issue resolved once that change is merged.

Please let me know if I can provide any value by exploring the XNA 4.0 behaviour for you.

That was good timing actually, I dug up my VS2010 VM and can confirm that the behavior matches now!