Looping sounds quit on WinRT

PaulH

I'm working on releasing an WinRT version of one of my games on the Windows Store. So far, so good, except that a background sound loop that should play forever doesn't repeat, and simply stops after being played once. I'm using Gideros 2015.10 at the moment. It works on the Gideros Player on Windows, and I haven't had any trouble with the Android or iOS versions, but after building the exported giderosgame.Windows project and running the result, the sounds don't seem to loop.

Has anyone else encountered this? Does anyone have any suggestions?

Paul

antix

See this thread

http://giderosmobile.com/forum/discussion/5644/gideros-player-2015-04-08-not-functioning/p1

PaulH

Thanks for sharing that. At first I thought that was leading me towards a solution, but I think my case may be different, however.

I'd forgotten that some time ago, for a number of reasons including to avoid slight gaps in playback and some strange crashes related to looping sounds, I changed the way this game plays its looping background. Rather than using the built-in looping feature, I continually check the position of the sound player, and if it's within a quarter second of the end, I jump it back to a quarter second in from the beginning. Doing this a quarter second before the end prevents the sound from ending between checks, and starting a quarter second in prevents a slight stutter I get if I try to start at the very beginning. The code to keep the sound looping looks like this:

if (sound_player[cat]:getPosition() > sound_length[cat] - 250) then
sound_player[cat]:setPosition(250)
end

This seems to be what's failing on the WinRT build. Perhaps SoundChannel:getPosition() or SoundChannel:setPosition() doesn't work on all systems. I'll try a few experiments to see if I can rule out either of those.

Paul

PaulH

I played around with some variations, and found that getPostion() and setPosition() are working on the Windows executable, but getPosition() may not always return an up-to-date value. The code to check the position is called every frame (about every 33 milliseconds) so detecting when the sound is within 250 ms of its end seemed safe. Widening that margin to 500 ms made no difference, but taking to a full second worked.

While I'm not seeing that happen when jumping back in the sound file a full second before the end, it's possible that in some environments even that may fail. So I've also added a safety measure - if it finds the sound is no longer playing, indicating it reached its end before any call to getPosition() showed it was close to doing so, the sound will be restarted. If that happens there's a tiny gap in the sound. In this case the background sound loop is that of a running river or stream of various speeds. In the louder and faster sounds, the tiny gap to replay the sound is noticeable, but it's far better than the sound simply stopping.

Paul

antix

So having an event fire when the sound has played (which then starts it again) does not work?

PaulH

I didn't try that, but I assume I'd get at least a slight pause between the end of one play and the start of the next, perhaps only a few milliseconds, but enough to be noticeable when the sound is something like a nearby waterfall.

antix

Ahh, I see. I don't know if there would be any noticeable popping or anything if it was just a few milliseconds.

SinisterSoft

You shouldn't be playing game sounds as mp3 - it should really be used for streaming background music. You should really use a wav sound for game sound effects, they should repeat fine.

john26

Are you playing WAV files or MP3? In Gideros, WAV files are automatically stored in memory while MP3 files are streamed off the disk so the behaviour can be different.

I think I can see a source of error in getPosition:

https://github.com/gideros/gideros/blob/master/libgid/src/gaudio-sample-xaudio2.cpp#L233

so offset is the number of seconds from the start of the sample and this is cast to an int before being multiplied by 1000 and returned so this would explain highly inaccurate numbers (no better accuracy than 1 second). I will fix this, sorry!

WinRT using an audio system called XAudio2 (all other platforms use OpenAL). On XAudio2, setPosition is potentially an expensive operation as there is no way to change the position of a "sourceVoice" directly as there is in OpenAL. Instead you need to destroy the sourceVoice and recreate it to start at the new desired position.

So overall, it might be better to simply use the built in looping feature and perhaps accept a slight glitch in the sound as it loops.

PaulH

In this game I use MP3s rather than WAVs for all the sounds to minimize space. The game comes in at over 49.5 MB, very close to the 50 MB threshold where it would be necessary to move content to an expansion file. I experimented with expansion files a year or two ago and found them... problematic.

I'm shooting content for a future version of this game, and the full set of content will far exceed 50 MB, so I'll have to work out the issues with expansion files in one form or another. Perhaps then I'll make the switch to WAV files. I might be able to tighten up a few things to free enough space to make the few sounds that loop into WAVs.

In the meantime things seem to be working well.

Thanks looking into the getPosition issue. Regardless of looping issues, it will be helpful to have that returning more precise values.

Paul