[Asterisk-Dev] Echo and Channel Monitor revisited

[Nicholas Romero]

Hello again... I did not want to throw this on the Users list because it is
really more a question about the structure of how the host based DSP and
Channel monitoring are implemented. I looking through the code and though
use of Asterisk it has become apparent that any significant load on a system
will introduce an artificial echo.  This is especially true if channels are
being monitored and recorded to files.

Number one I am wondering if my initial assessment of this has been observed
elsewhere.  Number two I am thinking that monitoring of channels my be
better served by restructuring of the mechanism.   These are just thoughts
off the top of my head and are expected to be shot down.

First create a stream/queue/buffer of some sort that consists of duplicates
of the frames that are just about to go out to the recipient. These frames
would have already gone though whatever DSPs are specified except for any
compression or transcoding from the native PCM format. The frames should
have some sort of timecode or sequence encoded with them.
Let anyone read this buffer and not just lock it to one destination as it is
now.  Keep a reference count as a possible artificial limit the number or
readers though. Make the buffer runtime sizeable. Start it at maybe one
minute of buffer for each channel.  I know this is a lot but could be
useful.  Let people seek in the buffer to anything within the current
buffer.
On the other side of this, instead of just connecting the monitor stream
directly to a file stream maybe do something else. Right now it seems to be
blocking the entire system when there is any sort disk contention.  Maybe
created a separate thread of a lower priority that will read from this
buffer in bursts and drop it into a file.  Also make the monitor app, or any
reader, cope with frame drops and sync issues itself rather then having the
stream writer do it.


Again, these are just ideas.  I can not test them out at the moment.  All my
systems are in production and a change like this is too risky.  I would like
some feedback though.

-Nicholas Romero
nick at idim.com