[Asterisk-Dev] Re: ztdummy accuracy improvements on kernel 2.6

[Tony Mountifield]

In article <2F9E2184-30BD-42AE-8F9D-EBC9F32A2435 at mac.com>,
Brian West <brian.west at mac.com> wrote:
> It is in fact a design flaw in meetme... We don't have the problem in  
> our app_confcall.  The issue is related to the enter exit tones and  
> the admin menu.  The design flaw in meetme causes the delay.  Every  
> enter/exit tone that is played lags X ms every single time its  
> played.  Then if you enter the admin menu you lag behind the amount  
> of time you spend in the admin menu.  This all stems from wanting to  
> be efficeient.  In our app_confcall we have an extra thread that does  
> nothing but play sounds and takes care of other misc tasks in the  
> conf.  Also We actually remove you from the conf when you go into the  
> menu to do any tasks.
> 
> So this is NOT a ztdummy issue because it can happen on any zaptel  
> card from digium.

Sorry Brian, you ARE talking about a different issue from me. I am well
aware of the issue with enter and exit tones and the admin menu - it
was I who posted the bug ID 3599 and proposed patches about that very
issue (mantis user softins). You even offered me your wall to bang
my head on!

Not only that, but the app_meetme on which I was noticing the ztdummy
effect ALREADY has my patches for playing entry and exit tones and
announcements in a separate thread. AND I was running with the 'q' flag
on all participants.  AND I wasn't using the admin menu. AND the delay
increased over time with just two static participants talking to each
other with no-one else entering or leaving.

I really DO know what I am talking about:

In order to track this issue down, I modified meetme to log to an array
the gettimeofday() and the bytecount for every channel frame received
from ast_read() when the channel was ready, and for every buffer read
from the outfd (pseudo channel). At the conclusion of the call, both
arrays were dumped out to CVS files so I could import them into Excel
and do some analysis.

With the existing ztdummy running under 2.6, there was both a lot of
jitter and a lot of drift on the data being read from the pseudo chan.
Over time, the average number of bytes per second, which should be
16000, would drift downwards, indicating missed ticks in ztdummy.

With my ztdummy modified to use the RTC interrupt, and NO other changes
(e.g. to meetme), the logged data showed that the data from both the
pseudo-channel AND the IAX channel was rock-solid on average. There was
a +/- 1ms jitter, which was not surprising, nor worrying, but the
long-term average stayed within 1 byte/sec of 16000. And repeating the
two-participant call I mentioned above demonstrated that the delay was
no longer increasing by any detectable amount.

I know from reading the list a while ago that MeetMe is a bit of a
personal issue for you, but there are other people who know stuff too!

Cheers
Tony

-- 
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org