PlaneShift

I can confirm that this happens at least occasionally in Windoze 2000. In my cases, upon re-focusing the soundtrack would be playing twice, likely desynchronised, at the same time. Entering another area often leaves one of them playing (probably the first one) and only changes the other, so that you get two different soundtracks playing simultaneously.

IIRC, whether this happens depends on the way you de-focus the window, so it seems like there's just one undetected case.

Well, I think the reason it happens with beryl, is that the window never knows it lost focus, the game is rendered off screen anyway, which allows for all the cool effects of active thumbnail views and transparent 3d cubes ;)

But this bug is not in the linux version when planeshift actually loses focus.

in options/sound.xml what is the value for
<muteonfocusloss on="no" />

if it is set to "no" i think this is the expected behavior

yes, that did it. So now the question is which are wrong:
- the default value being 'no'
- the test case (for sure it is not complete)

Maybe I'm confusing this with an actual bug, but in my sound.xml the value is "yes", and it still occasionally doesn't stop the sound when defocusing. Just yesterday I had the effect described above, after leaving the PS window through the task bar (which is set to auto-hide). IOW, the first time I clicked was when the mouse was over the "start" menu, at which time the PS window was inactive (grayed title bar), but the sound kept playing. After doing this a few times, a second sound instance started playing, so now the theme had gotten an echo effect.

I have not found a way to reliably reproduce this, though: sometimes it doesn't occur for an entire session, and other times it does happen mid-session, therefore I cannot rule out a problem with windows' messaging.

Edit: I've just now got it again: PS sound is playing while I edit this report. It seems to happen most often in East Hydlaa, maybe coming there from another zone is part of it as well.

Lanarel, would you mean that this specific test is incomplete or the test cases about sounds are not finished?
Because, for the first the answer should be no and for the second the answer is yes.

If also Seytra can confirm some problem with this feature, maybe it is time to mark this as new?

Arianna:
Yes, the test case is incomplete, as it does not test the yes/no option. Or, the option is not to be tested, but then it should always be on yes (which it was not for me, but was for Seytra?).
The problem Seytra mentioned with double sound is reported elsewhere by others, but I never had that occur, and would prefer that to be kept as a separate (non-regressiontest) bug. I will do some more tests though.
Since I am pretty sure either the default and/or the testcase is not OK, I was about to set this to new to get it to your attention (which it already got) so you can decide whether it needs assigning, or await me reporting things to update in the tests.

So the question here only is "should it be set to "yes" by default or not"? I didn't check what it was set to right after install, but I have changed the appropriate option in PSsetup or ingame (not sure which, but I guess it doesn't matter), producing the expected result (except the occasional double sound, obviously), and since it's set to "yes" now, I assume that the default was "no". I suppose that it being set to "yes" by default would be more logical, and more consistent with other games.

Ok, the test case was written by me and I usually didn't write half made things
So, the things are two (since I wrote such test cases about 2 years ago)
1) there was not such option back then
2) it was implicit that the parameter should be "yes"
and in the second case, there is a test case missing (to test the "no"), but the test case itself is correct.

If with "yes" is not working correctly we surely have a problem.

The file to be looked at is not options/sound.xml but options/sound_def.xml
That is the default.
In my default I have muteonfocusloss = no.
That is something that can be fixed through the options in the GUI.

If the default is no it might be just depending from Talad's settings

Default in sound_def.xml (for trunk, stable and 3.20 install) is no. I guess that should be yes. THe test case only is not correct if this option is something to be used :)

This is still unconfirmed. Should we mark it new to get something fixed if there is a problem or not?
If when the parameter is set to yet in the options, is the sound working as expected by the test case or not?

If the option is to be used there is a test case missing, not a uncorrect test case (see previous comment).

Setting to confirmed.

Solution: Make muteonfocusloss="yes" by default in sound_def.xml

Assigned to acraig and Talad. Please, check Thom's last message.

Default set to yes now. CLosing.