Menu
▾
▴
Re: [Iaxclient-devel] Some data related to the new bug...
|
From: Adam H. <ad...@te...> - 2004-04-17 01:40:28
|
Sorry :| That's pretty bad and I've never heard of it before (I guess it's a hardware issue) 90% of games run on QueryPerformanceCounter() so I guess it can't be too common. I'll fix up firefly, thanks for the information. Anything else I can 'help' you with :) -Adam Steve Kann wrote: > > Hey Adam, > > We took you advice here [thanks!], and used something based on > your code below, which was nice _most_ of the time. > > However, in my office, I have 3 different machines [out of only > about a dozen or so we've been using this code on regularly], where > this fails spectacularly. > > The problem is described here, and it is not theoretical. It > causes real problems for timing! > > http://support.microsoft.com/?id=274323 > > So, I've disabled this in iaxclient for now. My suggestion to you > for firefly is to just use GetTickCount, and deal with it's 10ms > accuracy. The 10ms for us isn't a problem, but the 5 second jumps I > saw really are! > > > -SteveK > > > Adam Hart wrote: > >>Why don't you guys just use my code from firefly, it's has nanosecond >>accuracy. Beats the hell out of 10ms accuaracy >> >>static __int64 freq,start; >>static int inited = 0; >> >>//static time_t startuptime; >> >>BOOL APIENTRY DllMain( HANDLE hModule, >> DWORD ul_reason_for_call, >> LPVOID lpReserved >> ) >>{ >> if(!inited) >> { >> >> inited = 1; >> QueryPerformanceFrequency((LARGE_INTEGER*)&freq); >> QueryPerformanceCounter((LARGE_INTEGER*)&start); >> } >> return TRUE; >>} >> >>void gettimeofday(struct timeval *tv, struct timezone *tz) >>{ >> __int64 time; >> double elapsed; >> >> QueryPerformanceCounter((LARGE_INTEGER*)&time); >> >> elapsed = (double)(time - start) / (double)freq; >> >> tv->tv_sec = (long)elapsed; >> tv->tv_usec = (long)((elapsed-tv->tv_sec) * 1000000); >>} >> >>enjoy, >> Adam >> >>----- Original Message ----- >>From: "Steven Sokol" <ss...@so...> >>To: <iax...@li...> >>Sent: Thursday, February 05, 2004 11:34 AM >>Subject: RE: [Iaxclient-devel] Some data related to the new bug... >> >> >> >> >>>Yes. Guilty as charged. It always happens UNDER WINDOWS. >>> >>>I believe that the gettimeofday() is being replaced by a function based on >>>GetTickCount(). I wonder if that doesn't have something to do with it. >>> >>>Steve S >>> >>>-----Original Message----- >>>From: iax...@li... >>>[mailto:iax...@li...] On Behalf Of Steve >>>Underwood >>>Sent: Wednesday, February 04, 2004 5:48 PM >>>To: iax...@li... >>>Subject: Re: [Iaxclient-devel] Some data related to the new bug... >>> >>>Steven Sokol wrote: >>> >>> >>> >>>>More notes: >>>> >>>>1. It ALWAYS happens. It is not an intermittent issue. This happens >>>> >>>> >>for >> >> >>>>EVERY IAX2-to-IAX2 call made using iaxClient. >>>> >>>> >>>> >>>> >>>Not EVERY call. I make hour long calls using iaxclient IAX2-to-IAX2 and >>>have no trouble. I use Linux. Is that the difference? >>> >>> >>> >>>>2. The timing is uncanny. It ALWAYS happens after 65-67 seconds. >>>> >>>>3. The audio dies but the call in not immediately torn down. The call >>>>eventually is eventually killed when the PING/PONG cycle times out some >>>>seconds later (perhaps over a minute in some of my tests). >>>> >>>>4. In EVERY case, the Asterisk kicks out the aforementioned voice frame >>>>retransmit message. >>>> >>>> >>>> >>>> >>>As Adam said, there is something wrong if a voice frame is being >>>retransmitted at that point in the call. Perhaps checking places where >>>the frame is tagged for retransmission would home in on the problem. >>> >>> >>> >>>>5. I don't see registration messages coming through at the same time. I >>>>was originally guessing that this happened during the re-reg process. >>>> >>>> >>Not >> >> >>>>so (or at least that doesn't seem to be the case -- could be that the >>>> >>>> >>>re-reg >>> >>> >>>>that takes place prior to the error causes a problem). >>>> >>>> >>>> >>>> >>>Regards, >>>Steve >>> >>> >>> >>> >>> > |
