Subject: Re: Various NetBSD kernel questions to help with port of FreeBSD "zaptel" drivers.
To: Ty Sarna <tsarna@sarna.org>
From: Thor Lancelot Simon <tls@rek.tjls.com>
List: tech-kern
Date: 11/08/2004 13:33:40
On Mon, Nov 08, 2004 at 12:37:02PM -0500, Ty Sarna wrote:
> > 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...).
> 
> I bow to your experience in this area, but in this case the hardware
> devices basicially *are* sound cards, are they not? They're just sound

That is certainly one way to look at it.  I just happen to think that it's
the wrong way.

It seems to me that extracting audio is just one of the many things you
might want to do with a telephony card; and it is by no means the principal
one in many applications.  In switching applications, for example, the
content of the audio stream matters no more than the content of a TCP
session matters to an Ethernet switch or an IP router.  Even in interactive
voice applications, generally the audio stream is parsed only to extract
certain execptional events: in-band signalling by touch-tones; and indeed
telephony cards generally report *only these tones* to the host CPU, as
events, unless specifically told otherwise.

You can use a telephony card as a sound card, but generally if you are
doing so, in most applications, you are doing something wrong.  In few
applications save voicemail is audio played or recorded to/from the
stream for most of the time the application is attached to a given stream
as a logical resource.  Even in those applications, the application
control flow is generally concerned with telephone events (including
in-band signaling) and *not* with putting/getting audio.  Indeed, such
applications generally manage many streams at once; and, in any large
installation, signalling and audio resources are decidedly distinct
entities and one may well have signalling resources attached _all_ the
time, but audio resources only occasionally (or not at all; one may
simply instruct the telephony fabric to patch them together, or to
patch, for example, an audio stream to a voice-recognition sink, which
will then provide a stream of text or token events to the application).

The sad fact of the matter is that code that runs on general-purpose
CPUs simply *cannot* do significant processing of audio data in any
significant telephony application.  As much of this work as possible
is offloaded to other processors; and so using a telephony card "like
a sound card" is very much the exception, not the rule.  I do not
believe that it makes sense to design an interface around this
exceptional case.

-- 
 Thor Lancelot Simon	                                      tls@rek.tjls.com
   But as he knew no bad language, he had called him all the names of common
 objects that he could think of, and had screamed: "You lamp!  You towel!  You
 plate!" and so on.              --Sigmund Freud