On Mon, Nov 08, 2004 at 11:35:53AM -0500, Thor Lancelot Simon wrote:
> On Mon, Nov 08, 2004 at 10:45:01AM -0500, Ty Sarna wrote:
> > In article <rmi7jow5ubl.fsf@fnord.ir.bbn.com> you write:
> > > The cleanest way: make the actual lower-level drivers have softcs, and
> > > make the upper layer into a pseudo-driver kind of like scsibus, usb,
> > > audio, atabus, pcmcia, etc.
> > 
> > Indeed, it seems to me like it would be especially nice if the upper
> > layer *was* the "audio" driver, or an extended variant thereof.
> 
> Wow, I don't think so.  Telephony is seldom concerned with the content
> of audio streams, and indeed one generally wants to keep them out of
> main memory if at all possible (in software VoIP applications, it's
> seldom possible, but that does not mean that one does not _want_ to
> avoid hauling it into memory and working on it there...).
> 
> Generally, telephony is concerned with _where audio goes_, not
> _what's in it_.  And it requires an interface for controlling where
> audio goes that is _much_ more sophisticated and precise than, for
> example, our "mixer" interface.
> 
> I really think it is tremendously wrong to produce a telephony interface
> unlike every other extant one, one bent to look like a simple audio
> driver when in fact one would really like to _avoid_ having to treat the
> audio data at all.
> 

Thor,

You seem to advocate splitting policy and mechanism between userland
(Asterisk routes calls) and the kernel (merely copies audio frames from
line card to line card, or from line card to VoIP, or VoIP to VoIP)
so that audio is not needlessly copied between userland and the kernel.
Is that about right?  Can you give a positive account of what the kernel
architecture will look like?

I would ask of the original poster, does the Asterisk architecture
observe this policy/mechanism, userland/kernel split?

(I am dimly aware that STREAMS has something to do with all of this.)

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933