TGEA 1.7.0 Bug: intermittent SFX preload errors
by Jeff Faust · in Torque Game Engine Advanced · 04/07/2008 (9:43 am) · 27 replies
I'm still trying to discover additional information about this, but what I'm observing is intermittent SFX preload errors on certain sounds. The errors are of the form:
SFXProfile(CrossbowFireSound)::onAdd: The preload failed!
While the error seems to be reported consistently for certain files (both of the ones I see are in ogg format), the errors are inconsistent from load to load. Sometimes there are no errors and the audio files will play. Other times the preload errors occur and the sounds won't play. It's possible to get preload errors on the first mission load, exit the mission, then reload the same mission without exiting the app, and get no errors and the sounds will then play.
When the errors do occur they appear to result from a SFXResource::load() call returning NULL.
SFXProfile(CrossbowFireSound)::onAdd: The preload failed!
While the error seems to be reported consistently for certain files (both of the ones I see are in ogg format), the errors are inconsistent from load to load. Sometimes there are no errors and the audio files will play. Other times the preload errors occur and the sounds won't play. It's possible to get preload errors on the first mission load, exit the mission, then reload the same mission without exiting the app, and get no errors and the sounds will then play.
When the errors do occur they appear to result from a SFXResource::load() call returning NULL.
About the author
Jeff Faust creates special effects indie middleware and games for Faust Logic. --- Blog: Effectronica.com --- Twitter: @FaustLogic
#2
This has all the earmarks of having an indirect cause, such as an initialization problem or a buffer overrun. Different executions produce different results. I've even tried repeated loading of the troublesome files in a loop, and sometimes after a few failures, it suddenly loads correctly.
04/07/2008 (2:03 pm)
This is one of those wacky bugs that are really hard to pinpoint. It doesn't help that it never happens with debugging on, but with the help of hard-coded error messages, I was able to follow the code flow. Specifically, the intermittent preload errors happen because deep inside the ogg reader, an unexpected end-of-file is encountered, but it's hard to say why.This has all the earmarks of having an indirect cause, such as an initialization problem or a buffer overrun. Different executions produce different results. I've even tried repeated loading of the troublesome files in a loop, and sometimes after a few failures, it suddenly loads correctly.
#3
I have found in the past that ogg format files can exhibit strange behaviors with short duration sounds. Both of the sounds here have short durations so perhaps this has something to do with that.
04/07/2008 (2:55 pm)
OK, final word on this for now. It turns out that I can reproduce this in stock Stronghold mission. I thought it was loading Crossbow_firing.ogg, but it was loading an alternative instead. Once it loads Crossbow_firing.ogg, it starts reporting the same preload errors I was getting in my own app. I have found in the past that ogg format files can exhibit strange behaviors with short duration sounds. Both of the sounds here have short durations so perhaps this has something to do with that.
#4
Never noticed the errors with Beta 2 or Beta 1 though.
04/07/2008 (3:12 pm)
I also get the same preload errors with the 1.7 release. (This is with a fresh install. Happens on both Stronghold and T3D examples)Never noticed the errors with Beta 2 or Beta 1 though.
#5
04/07/2008 (3:19 pm)
Note - most of the obvious preload errors in Stronghold and T3D are due to the fact that a .wav is requested when an .ogg exists or vice-versa. Those used to be silently handled in older versions, but SFX is pickier. These preload errors are slightly different than the intermittent errors. For one, they are not intermittent.
#6
Make sure each of the defined SFXProfile's fileName doesn't specify an extension. An extension does not need to be specified and by not explicitly saying .ogg or .wav it will allow you to change from one format to the other without having to change the scripts.
Second,
Make sure that server SFXProfiles are defined with the datablock keyword, and that client SFXProfiles are defined with the 'new' keyword. If you don't know (you really should know tho!), specify with datablock.
Third,
Make sure SFXDescriptions exist for your SFXProfiles. Also make sure that SFXDescriptions are defined BEFORE SFXProfiles. This is especially important if your SFXProfiles are located in different files than your SFXDescriptions. In this case, make sure the files containing SFXDescriptions are exec'd before the files containing the SFXProfiles.
Fourth,
Make sure that server SFXDescriptions are defined with the datablock keyword, and that client SFXDescriptions are defined with the 'new' keyword. If you don't know (you really should know tho!), specify with datablock.
Fifth,
I don't have a copy of TGEA 1.7, but someone should check to make sure that Sim::findObject is not called inside SFXProfile's unpackData method. If it is, this is a BAD BAD BUG and someone should tell me so I can thunk some skulls.
04/07/2008 (8:10 pm)
First,Make sure each of the defined SFXProfile's fileName doesn't specify an extension. An extension does not need to be specified and by not explicitly saying .ogg or .wav it will allow you to change from one format to the other without having to change the scripts.
Second,
Make sure that server SFXProfiles are defined with the datablock keyword, and that client SFXProfiles are defined with the 'new' keyword. If you don't know (you really should know tho!), specify with datablock.
Third,
Make sure SFXDescriptions exist for your SFXProfiles. Also make sure that SFXDescriptions are defined BEFORE SFXProfiles. This is especially important if your SFXProfiles are located in different files than your SFXDescriptions. In this case, make sure the files containing SFXDescriptions are exec'd before the files containing the SFXProfiles.
Fourth,
Make sure that server SFXDescriptions are defined with the datablock keyword, and that client SFXDescriptions are defined with the 'new' keyword. If you don't know (you really should know tho!), specify with datablock.
Fifth,
I don't have a copy of TGEA 1.7, but someone should check to make sure that Sim::findObject is not called inside SFXProfile's unpackData method. If it is, this is a BAD BAD BUG and someone should tell me so I can thunk some skulls.
#7
04/08/2008 (8:04 am)
@ Robert -- All good advice, but a list of "best practices" doesn't eliminate the bug which is the topic of this thread. The bug of note is an intermittent failure to preload certain ogg files and it occurs in the stock Stronghold mission even after the demo has been corrected to follow the best practices you list. In fact, it would be great if the stock demos actually practiced these best practices. Several of them report a number of console errors because the don't follow them. Also, SFXProfile's unpackData method does not call Sim::findObject(). 
#8
04/08/2008 (10:53 am)
I'll take a look at this tonight. 
#9
I haven't checked the datablocks yet.
04/08/2008 (4:17 pm)
Loading light datablocks from: common/lighting/filters/ SFXProfile(DeathCrySound)::onAdd: The preload failed! SFXProfile(PainCrySound)::onAdd: The preload failed! SFXProfile(FootLightBubblesSound)::onAdd: The preload failed! SFXProfile(ArmorMoveBubblesSound)::onAdd: The preload failed! SFXProfile(WaterBreathMaleSound)::onAdd: The preload failed! SFXProfile(ImpactLightSoftSound)::onAdd: The preload failed! SFXProfile(ImpactLightHardSound)::onAdd: The preload failed! SFXProfile(ImpactLightMetalSound)::onAdd: The preload failed! SFXProfile(ImpactLightSnowSound)::onAdd: The preload failed! SFXProfile(ImpactLightWaterEasySound)::onAdd: The preload failed! SFXProfile(ImpactLightWaterMediumSound)::onAdd: The preload failed! SFXProfile(ImpactLightWaterHardSound)::onAdd: The preload failed! SFXProfile(ExitingWaterLightSound)::onAdd: The preload failed!This is what I get in the stronghold mission.
I haven't checked the datablocks yet.
#10
04/08/2008 (6:25 pm)
Weird... i don't get that from the repo build. I'll install and check the SDK release... maybe something went missing.
#11
This should be the only change needed. I had it fail in repo build also.
Oddly enough, after this change, both CrossbowFireSound and CrossbowFireEmptySound fail, whereas CrossbowFireEmptySound loads the same sound fine before the change.
Anyway, that's what happens for me. If you can't repro with this example it must be local to my setup.
04/08/2008 (7:14 pm)
To repro in stock Stronghold you have to change CrossbowFireSound in crossbow.cs to use crossbow_firing.ogg. datablock SFXProfile(CrossbowFireSound)
{
//filename = "~/data/sound/relbow_mono_01.ogg";
filename = "~/data/sound/crossbow_firing.ogg";
description = AudioClose3d;
preload = true;
}; This should be the only change needed. I had it fail in repo build also.
Oddly enough, after this change, both CrossbowFireSound and CrossbowFireEmptySound fail, whereas CrossbowFireEmptySound loads the same sound fine before the change.
Anyway, that's what happens for me. If you can't repro with this example it must be local to my setup.
#12
04/20/2008 (10:03 pm)
Any news or update on this? I get sfx preload errors a lot.
#13
The intermittent failure is less common. Also, it appears to be exclusive to ogg format, so you can probably work around it by switching to wav for any problematic audio file. Working with ogg format, I've found that it can become fairly unstable for short duration audio samples and this bug may be related to that.
04/21/2008 (5:54 am)
FYI - The error that says "The preload failed!" is thrown by a number of different failures. For example, referencing a non-existent audio file does it, and you also get it if the SFXProfile explicitly specifies an ogg when what exists is a wav, (and the other way around). Many of these are easily fixed by matching up the assets correctly and not loading those that don't exist. The intermittent failure is less common. Also, it appears to be exclusive to ogg format, so you can probably work around it by switching to wav for any problematic audio file. Working with ogg format, I've found that it can become fairly unstable for short duration audio samples and this bug may be related to that.
#14
edit: Btw, are you having any problems with short duration wavs not playing at all? I have a sound file that is less than a second long. It is mono, and would not work with OGG. After reading this thread, I tried wav, and it still doesn't play. Yet it plays fine in every other application that I have tried, i.e. windows media player, winamp, and audacity. However, other short duration sound files that come stock seem to work fine. I use audacity to edit and export to wav/ogg.
04/22/2008 (3:42 pm)
Thanks, Jeff, I'll stick to wavs for right now.edit: Btw, are you having any problems with short duration wavs not playing at all? I have a sound file that is less than a second long. It is mono, and would not work with OGG. After reading this thread, I tried wav, and it still doesn't play. Yet it plays fine in every other application that I have tried, i.e. windows media player, winamp, and audacity. However, other short duration sound files that come stock seem to work fine. I use audacity to edit and export to wav/ogg.
#15
05/12/2008 (12:54 am)
I can confirm that short ogg files arent played correctly.
#16
05/24/2008 (7:35 pm)
Could anyone here that is having trouble with a particular ogg file send it to me? tom@sickheadgames.com
#17
@Jeff - Could you try out the repo version and see if you have the same issues in Stronghold?
05/25/2008 (3:50 pm)
Ok... i haven't been able to recreate this issue in the downloaded SDK or in the repo.@Jeff - Could you try out the repo version and see if you have the same issues in Stronghold?
#18
05/28/2008 (5:11 am)
I never added the Notify... I will send you some of my files (which are just files from the Mojo packs). 
#19
It happens with the same files as Jeff described, and usually they are pretty short in length.
We only use VorbisStream in our repo and rolled our own AudioResource code, so because I messed up somewhere we get into an infinite loop instead of (as in TGEA's case) reporting back as an error. This is interesting because it led me to a while loop shown below.
On the exact same files as Jeff mentioned, that's where it loops and loops. So it must be something in there.
06/09/2008 (7:15 am)
Just ran into this as well when we played around with VorbisStream.It happens with the same files as Jeff described, and usually they are pretty short in length.
We only use VorbisStream in our repo and rolled our own AudioResource code, so because I messed up somewhere we get into an infinite loop instead of (as in TGEA's case) reporting back as an error. This is interesting because it led me to a while loop shown below.
long OggVorbisFile::_get_next_page(ogg_page *og,int boundary)
{
if(boundary>0)boundary+=vf->offset;
while(1){
long more;
if(boundary>0 && vf->offset>=boundary)return(OV_FALSE);
more=ogg_sync_pageseek(&vf->oy,og);
if(more<0){
/* skipped n bytes */
vf->offset-=more;
}else{
if(more==0){
/* send more paramedics */
if(!boundary)return(OV_FALSE);
{
long ret=_get_data();
if(ret==0)return(OV_EOF);
if(ret<0)return(OV_EREAD);
}
}else{
/* got a page. Return the offset at the page beginning,
advance the internal offset past the page end */
long ret=vf->offset;
vf->offset+=more;
return(ret);
}
}
}
}On the exact same files as Jeff mentioned, that's where it loops and loops. So it must be something in there.
#20
Edit: Try lowering the maximum loop count if you're not seeing any improvements. I guess the fact that it does loop indefinatly on our end makes the above hack perhaps useless in stock TGEA.
I was suspecting that this had to do with bumping into the end of the file too early and reading too large chunks when a file is smaller than the buffer size, but it doesn't seem to be it. Try setting boundary to something small, like 1. Suddenly (at least here.. havent reprod in TGEA 1.7 yet) all sounds load, but they chop of at the end if they're larger than a few seconds.
06/09/2008 (8:39 am)
Can anyone confirm if this hack works with short sounds? It does on my end. Trying to find a real solution now.long OggVorbisFile::_get_next_page(ogg_page *og,int boundary)
{
if(boundary>0)boundary+=vf->offset;
int counter = 0; //+
while(1)
{
counter++; //+
if (counter > 1000000) //+
{ //+
return(OV_EOF); //+
} //+Edit: Try lowering the maximum loop count if you're not seeing any improvements. I guess the fact that it does loop indefinatly on our end makes the above hack perhaps useless in stock TGEA.
I was suspecting that this had to do with bumping into the end of the file too early and reading too large chunks when a file is smaller than the buffer size, but it doesn't seem to be it. Try setting boundary to something small, like 1. Suddenly (at least here.. havent reprod in TGEA 1.7 yet) all sounds load, but they chop of at the end if they're larger than a few seconds.
Associate Jeff Faust
Faust Logic, Inc.
The audio files that trigger these preload errors are stock files that can be found in Stronghold demo:
Crossbow_firing.ogg
Crossbow_firing_empty.ogg
However, I have not seen preload errors for these files in the Stronghold demo, only my app. I'm currently looking for clues as to what might be triggering these intermittent failures in my app.