[Asterisk-Dev] Help Debugging Dropped Call Audio - Possibly Fixed

[Kevin P. Fleming]

Matthew Roth wrote:

> It appears that poll() can return that one or more of the file 
> descriptors have events on them that are ready to be handled, but 
> ast_waitfor_nandfds() only returns a single "winner."  Is 
> ast_waitfor_nandfds() properly handling the case of multiple file 
> descriptors signaling?  Forgive me if that is a naive question.  I've 
> been working on our implementation for about half a year on many diverse 
> aspects, but I've only recently started to inspect the code.  It is well 
> written and well documented, but some of it is still difficult to 
> comprehend without asking questions.

You are correct that only a single 'winner' is returned, but the next 
call into ast_waitfor() will still find the non-winner as 'ready' and 
will return it. The file descriptors will stay marked 'ready' until the 
data has been read, regardless of how many times poll() is called on them.

> I'm curious to know if writing to some memory structure such as a queue 
> has been considered.  A separate writer thread could then be responsible 
> for servicing this queue parallel to Asterisk's handling of the call 
> itself.  We have a huge amount of memory to play with in our machine (20 
> GB), but some sort of dynamic queue structure and a writer thread may 
> help on lighter servers.

That's what MixMonitor uses.

> Out of all of this information, one thing seems clear to me.  The 
> servicing of the channels in ast_generic_bridge() and the Monitor() 
> related code in ast_read() and ast_write() don't play well with each 
> other.  Both ast_read() and ast_write() use chan->insmpl and 
> chan->outsmpl to determine if they need to call ast_seekstream() to jump 
> the file pointer ahead in one of the leg files to keep them 
> synchronized.  It seems that the problem centers around ast_seekstream() 
> being called based on an assumption that the chan->insmpl and 
> chan->outsmpl variables are being incremented on a one-to-one basis, 
> while ast_generic_bridge() calls ast_read() and ast_write() on a 
> schedule that is nearly, but not quite, one-to-one.  Every so often, 
> this leads to ast_seekstream() being called to fill in the gap for data 
> it assumes is missing, but will be received within the next couple of 
> loops of ast_generic_bridge().

Have you tried recording in another format which may be more resistant 
to these seeks? It would be interesting to see if there is a difference.

> I apologize if I'm a little overzealous in trying to address what are 
> relatively minor issues, but I feel as if I've been running a marathon 
> at a sprint for the last few months.

We all are very interested in making sure that Asterisk performs as well 
as it can in every situation where it makes sense... Your ability to 
diagnose and follow the code has been helpful, since you now understand 
where the problems are coming from :-)