Looping sounds quit on WinRT

Comments

• antix Member

  January 2016

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

  Likes: SinisterSoft

  +1 -1 (+1 / -0 )Share on Facebook
• PaulH Member

  January 2016

  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
  

  +1 -1Share on Facebook
• PaulH Member

  January 2016

  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
  

  +1 -1Share on Facebook
• antix Member

  January 2016

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

  +1 -1Share on Facebook
• PaulH Member

  January 2016

  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.
  

  +1 -1Share on Facebook
• antix Member

  January 2016

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

  +1 -1Share on Facebook
• SinisterSoft Maintainer

  January 2016

  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.

  Likes: MobAmuse

  Coder, video game industry veteran (since the '80s, ❤'s assembler), arrested - never convicted hacker (in the '90s), dad of five, he/him (if that even matters!).
  https://deluxepixel.com

  +1 -1 (+1 / -0 )Share on Facebook
• john26 Maintainer

  February 2016

  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.

  http://giderosmobile.com
  https://github.com/gideros/gideros
  https://www.youtube.com/c/JohnBlackburn1975
  

  +1 -1Share on Facebook
• PaulH Member

  February 2016

  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
  

  +1 -1Share on Facebook