Audio glitch? Bug? Gremlin? Hardware issue??
Blitz3D Forums/Blitz3D Programming/Audio glitch? Bug? Gremlin? Hardware issue??
| ||
| So basically, while playtesting my game recently, I've noticed a tendency to crash when excessive audio is played using PlaySound(). I don't mean a Blitz crash, either, I mean a hard Windows "blitcc.exe has stopped working" crash-a-palooza. I wondered if that might be caused by some kind of no-more-voices-than-this-playing-at-once-or-SCREW-YOU limit in audio hardware, so I created a special system wherein ALL non-3D audio (hardly using EmitSound() at all in my game, NOT at all in this particular test) is confined to 8 channels, BGM included. The system is simple: if a sound is called, the seven SFX channels (BGM is kept separate) are checked to see if one is empty, no audio playing. If all seven are engaged, the new sound picks the channel that was started the longest ago, stops it, and uses it. Also, there are some special sounds that can't be stopped, like speech inserts, which are marked by a "locked" tag; should all seven channels be occupied by locked audio, then the new sound is simply skipped. The end result is that, during this test, there were NEVER MORE THAN EIGHT SOUNDS PLAYING AT ONCE. That seemed to fix it for a bit, but after more testing, eventually it started cropping up again, same ol' WinCrash. So, are there any audio issues with Blitz or sound hardware in general I should know about? To put things in perspective, in this extremist test there were new sounds being started on more or less every frame at 60 FPS; could this be causing some sort of memory leak in the audio buffer? I honestly know very little about what goes on under Blitz's audio hood. |
| ||
| Well, the simplest way to check for memory leaks is to keep an eye on memory usage. Run the apps until they crash, possibly with Task Manager open in the background so you can observe the memory behaviour. If it climbs uncontrollably, it may well be a memory leak (I don't see why it would be a memory leak unless you're loading the new sounds from disk while runningk, but I don't know how the sound system works at all). Also, have you made sure its the sound causing this? i.e. by pulling out the sound system to a new project, getting rid of all of the gameplay and 3D graphics and so on. It may not be practical to break this down into element by element, but it's good to try to eliminate factors. |
| ||
| Yeah, of course. I ran the same stress test - which was designed to test graphical performance - with the sounds disabled, meaning that they weren't being called, not that they were simply muted. No crash. I've had a similar issue to this on my netbook for some time now, but as she's an Asus EEE, that means she has no actual audio hardware, which gives her issues from the start with sound in some games, can't play MIDIs well, etc. Now, however, it looks like a similar problem may be appearing on my desktop PC, which DOES have sound hardware, so I'm a little concerned. Last edited 2011 |
| ||
| Continuing on Yasha's theme, you should create a program with just the audio part and get it to reproduce the crash if possible. All you proved so far was that removing the audio resulted in no crash, but that could be because the additional stress of the audio was too much in some way. If you can cause the crash by running the audio part only, then you will be sure it is the audio. Also; you are starting a sound every frame? I would expect that to crash a system. I haven't done much work with sounds, but I run droning sounds continuously (music, engine noise, wind, etc.) using LoopSound and PlaySound and just adjust the volume as necessary. So I only start them once. For event based sounds your approach may be fine, but maybe you need to add a timer so there is at least a 100ms delay between starting new sounds (or whatever gap works). That's just a guess. Is it really necessary to start a sound effect so soon after another? |
| ||
| Just on the offchance, does the WinCrash info mean anything to anyone here? Problem signature: Problem Event Name: APPCRASH Application Name: blitzcc.exe Application Version: 0.0.0.0 Application Timestamp: 4cb39aa9 Fault Module Name: runtime.dll Fault Module Version: 0.0.0.0 Fault Module Timestamp: 4cb3b68e Exception Code: c0000005 Exception Offset: 000ce869 OS Version: 6.1.7600.2.0.0.256.1 Locale ID: 1033 Additional Information 1: 0a9e Additional Information 2: 0a9e372d3b4ad19135b953a78882e789 Additional Information 3: 0a9e Additional Information 4: 0a9e372d3b4ad19135b953a78882e789 |
| ||
| Is it perhaps a corrupt sound file (.wav or otherwise?) |
| ||
| Oh... Crap. What the hell have I done. Guess what; after a few minutes of continuous stress test, I managed to crash the game again... WITH THE AUDIO DISABLED. Okay now, I'm just plain scared. This is just arbitrarily crashing Blitz itself, SOMETHING, SOMEWHERE in my code. I've got over five thousand lines relevant to this crash-inducing test, which by the way is just repeatedly playing the same level over and over with 200 enemies (each of which splits into 8 minis when destroyed, making a total of 1800 enemies by the time the level's finished, though not all at once) and all the graphical settings at maximum. There is no helpful Blitz error message, nothing from Debug Mode to help me out, no info on when or where it crashed; I tried running it in Debug mode, with sounds on it just froze completely at crash point, sounds off it simply vanished at crash with no word whatsoever. The bottom line is that for all the information given to me, the problem could be literally anywhere. I'm too far in right now to be able to pick apart every line of my code piece by piece, there's over 350KB in here and I don't even have a vague starting point for reference. The crash occurs at different times, even; it seems to occur sooner if audio is enabled, like maybe after I've gone through the level twice, whereas with sounds off it can take up to five or six mind-numbing re-play-throughs to reach. I have absolutely no idea what's causing this, where it's located, when it's occurring, or how to fix it. For the first time ever, I literally don't have a clue what to do, and I'm about halfway through, I can't stop now, I can't start over, I could end up spending the rest of my LIFE on this one game that I frankly should've had released a YEAR ago if I'd put the proper hours into it. I guess if I'm honest, I'm panicking a little, which I never normally do, but I'm freaked out; what the hell am I supposed to do?? Last edited 2011 Last edited 2011 |
| ||
| Are you using banks, if you reference an area outside of the bank's allocated space that can cause a crash with no useful error message sometimes? It's very easy to make a mistake with offsets within banks. There could be many areas which could be a problem, but that's one guess. |
| ||
| I've got over five thousand lines relevant to this crash-inducing test ... what the hell am I supposed to do?? I know the feeling! The zeroth thing is to not panic. I have absolutely no idea what's causing this, where it's located, when it's occurring, or how to fix it. The first thing is to keep testing until you can reliably replicate the crash. You'll have to be able to make the game crash on demand to be able to have a chance of finding it when it happens. Once that's done, you should have at least some idea of the vague area where it is (at least, if it happens ten minutes into gameplay you can be sure that it's not in the graphics setup). At this point, the Stop command and DebugLog (and IDEal's block-comment/block-uncomment) are your most powerful allies. Combine them thus: first, comment out every single thing that looks "safe" and non-essential (e.g. you can usually remove things like the HUD drawing if you're using a pre-made drawing library, 'cause it'll be solid). Each time (or not, depending on how slow testing is) go back and confirm that you can make it crash again; you can then assume for the moment that those areas aren't causing the problem. If the circumstances of the crash change (for reasons other than taking less time to load that point, obviously), you've got a relevant area. However, don't do this for everything: this is mainly to remove the little things from the equation that are highly unlikely to be helpful in finding the bug. Then, in the remaining complex-logic code, scatter Stops or DebugLogs every n lines (where n is really defined by your code structure), having DebugLog mark your current point and using Stop to check the status of things quickly. A tip is not to put Stop in dense loops as it'll take you forever to step through them. Eventually you'll reach the last point before things crash... and you can narrow it down from there, adding more breakpoints in the program logic as necessary to let you step through until the crash itself happens. This is where, somewhere along the line, you're hoping to see something's gone wrong, and then do the other step (which this margin is too small to contain) where you actually fix it. Sorry if that was very basic, but it works. It may take some time though. As for current information... well that info above means nothing to me. Are you using any third-party libraries? Messing about with |
| ||
| Hmm, nope, no banks. The thing that concerns me most here is that so far, it seems like commenting sections (like audio) just makes the game take longer to crash, which A) makes no sense to me and B) means that it might SEEM stable after a certain point, but the crash-inducer could still be there just waiting out of sight, needing slightly longer than my test. In other words even if it looks like it's solved, I'm gonna be paranoid now that it's still waiting in there somewhere. Guh. |
| ||
| If you are so far in coding your program, I would suggest, instead of commenting out lines, looping extra through suspect pieces of code. Hope You can find the culprit. |
| ||
| it seems like commenting sections (like audio) just makes the game take longer to crash, One other thing I've seen people do (haven't had cause to use this myself) is to take advantage of the fact that writing to the debug console doesn't stop the program, and abuse the last line of the debug log as a "current status" bar, which lists the name of the current procedure (or sub-block, if you have very long procedures), by putting a DebugLog line at the top of every function body ("Entering function: LoadStuff" etc.). This is probably a lot more useful than stepping through if it takes several minutes to crash (as otherwise you'd be hitting Step for years). Once you find the offending procedure, you could then add more DebugLog notifications, to give you an idea of what's going on without having to Stop execution. (I'm assuming from your comment above - that Debug mode didn't help - that the error does still occur in Debug mode: there are a few cases where Debug and Release don't always work the same way.) Last edited 2011 |
| ||
| Yasha, that might just help me out. Like PERFECTLY. The DebugLog() command won't work in this case, of course, since with Debug mode on it just went NO U and vanished, but if I instead use WriteFile() I might just be able to track this thing down. |
   |