Zitat von Martin Wache <[EMAIL PROTECTED]>: > Stefan Lucke schrieb: > > On Samstag 30 September 2006 20:04, Marko Mäkelä wrote: > >> On Sat, Sep 30, 2006 at 05:32:06PM +0100, Laz wrote: > >>> I usually let mine turn itself on and off with nvram-wakeup! I see > >>> the problem when I leave it for a short while in the middle of something > >>> and get distracted! > >> Me too. Sometimes, I hit the Power button followed by some other button > >> to suspend the playback and to prevent the system from powering off. > >> Then, I'd hit the Power button to resume. > >> > >>> Hmmm...if you're right about this, how long should it take to overflow? > >>> The > >>> only counter I can see is a 64-bit integer which looks like it's counting > >>> in > >>> useconds which would take a few million years to overflow, by my > >>> reckoning! > >>> Maybe I'm looking in the wrong place and it's a 32-bit counter which would > >>> take 1 h 12 min to overflow. Not sure it was taking that long but it's > >>> hard > >>> to tell. > > > > Negative values should not harm,as we would return immedeatly. > > > I think the problem is in cSyncTimer::GetRelTime() which returns an > signed int. If GetRelTime() returns a negative number because of an > overflow we will actually add that value to delay instead of > substracting, when we do the ususal delay-=GetRelTime().
The -= operator is the one which is causing troubles. I guess we should introduce a private member "clampValue" , and return values of TimePassed() and GetRelTime() should be clamped to +/- clampValue if it is nonzero. The one thing which I cannot recalulate is: I had a sleep time of 27min (0x634cc13f usec). Time passed between pause/play was about 42min 50sec (0x992f1680 usec) . > > We could avoid this by letting GetRelTime() return some maximum, if > there have been overflows. This would fix the pause problem as well as > Marco's problem. > > Bye, > Martin > _______________________________________________ > Softdevice-devel mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/softdevice-devel > _______________________________________________ Softdevice-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/softdevice-devel
