Subject: Re: Various NetBSD kernel questions to help with port of FreeBSD "zaptel" drivers.
To: Ty Sarna <>
From: Thor Lancelot Simon <>
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	                            
   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