[asterisk-dev] patch for video display on chan_oss.c

[Russell Bryant]

Luigi Rizzo wrote:
> even more awesome is the fact that if you don't have X, ffmpeg will try
> to use aalib to render the output... which at videoconf resolutions
> is not _that_ unreasonable...

That is actually pretty hilarious.  :)

> BTW what's the status of your effort on chan_console so
> we can possibly avoid duplicating the functionality in alsa/oss ?

The only functionality that chan_console has that chan_alsa or chan_oss do not 
have is the ability to support the Mac sound system (core audio), and a number 
of others which aren't as applicable to Asterisk.  (It uses libportaudio).  I 
copied a lot of code from chan_oss, so the code is pretty similar to that.

It works well enough for my personal use, but it could eventually become the 
single console channel driver with some more effort.

Here is a list of what features alsa/oss have that chan_console does not:

* Multiple device support
* Setting auto-answer from the dialplan
* Some CLI commands: flash, transfer, autoanswer, boost, active

In addition to matching all of the existing functionality, here are some more 
things that I wanted to do before I considered it trunk-worthy:

* Remove the uses of busy.h, ringtone.h, etc.  Asterisk has an API for 
generating these tones on a channel, and it seems to make more sense to use that 
instead of doing it manually.  The API is in indications.h.  Another benefit of 
using this API is that it can use localized tones instead of the ones hard coded 
into the header file.

* There is some special handling for the write_buf to ensure that packets of 
audio are written to the audio device in 160 sample chunks.  There is an API for 
this, as well.  It is the ast_smoother API defined in frame.h.  Unfortunately, 
the API is almost completely undocumented.  However, it should help simplify the 
code a bit.

* I need to go back and better document some deadlock avoidance code I added to 
the console_hangup() function, because it isn't obvious to me why it was needed, 
and it has been long enough to where I have forgotten.

-- 
Russell Bryant
Software Engineer
Digium, Inc.