 |
chan->openalStreamingOffset += MIXBUFFER_SAMPLES; if(chan->openalStreamingOffset<0) chan->openalStreamingOffset = 0; ? Can it ever be negative outside of overflow? If no, change idSoundChannel::GatherChannelSamples to unsigned int? Make use of int64? |
 |
I think it could. Otherwise you have to ensure that start time of sound is never greater than current time. It is a dangerous assertion (some part of sound system works in another thread). I have already fixed the problem locally by restarting the sound channel when its offset gets too large. This is not very nice (sound restarts), but it is simple and it surely does not affect anyone unless they listen to the same sound 6 hours without pause. So this sound restart happens only after 6 hours, and only once per 6 hours... Now I am waiting for 15-hours experiment to complete =) |
|
|
Here is the suggested fix: // 0004803 stgatilov: avoid offset overflow (which causes crash) if (chan->openalStreamingOffset * sample->objectInfo.nChannels > INT_MAX - (1<<20)) { //simply restart this sound (happens after 6.75 hours of repetition) chan->trigger44kHzTime = current44kHz; chan->openalStreamingOffset = 0; common->Warning("Restarted sound to avoid offset overflow: %s", chan->leadinSample->name.c_str()); } |
|
|
Fixed in svn rev 7423. |
- Anonymous
