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