Re: drivers/telephony and winmodems

From: Steve Underwood (steveu@coppice.org)
Date: Mon Jan 17 2000 - 09:15:41 EST


Alan Cox wrote:

> > Given that telephony device is nothing but soundcard with few more
> > functions, and slightly obscure format, why is not drivers/telephony
> > more similar to drivers/audio?
>
> Mostly because the telephony cards that do audio tend to be fixed buffer
> sizes and codecs doing hardware enode/decode.
>
> > It gives sense to splay -d /dev/telephony0 /big/something.mp3, it
> > gives sense to record sounds from telephony line with exactly same
> > software you grab from soundcard. Yes, ixj is able to do fancy things
> > like DTMF detection in hardware, but don't expect that from DSP-less
> > winmodems. (And I'd expect winmodems to go just into
> > drivers/telephony, or not?)
>
> Probably. I would like to see telephony cards that can do plain raw 8/16bit
> samples also support the OSS API too. It seems only reasonable to be able
> to open a telephomny device and attach ibm viavoice to it for example

The present telephony framework in 2.2.14 (though clearly in its infancy)
seems to only deal with a narrow class of requirements - simple
telephony cards, acting as little more than channel by channel telephone line
interfaces. It doesn't seem to provide well for more powerful CTI cards, which
keep much of the audio activity on a mezzanine switching fabric bus (MVIP,
SCBUS or S.100). My question is, what are the real intentions of this
framework?

On other Unixen (and the Non-functional Telephony platform) every CTI vendor
has their own interfaces (someone say "TAPI". I need a good laugh). With
nothing to apply suitable pressure they are going to do the same on Linux,
when they finally wake up and get serious about it. Some vendors (e.g. Pika
and NMS) have had beta drivers for months, with little progress. It is unclear
what their real intentions are. Dialogic looks like it is about to enter the
frey, with more beta drivers. Again its intentions are unclear, but I'm damned
certain a core intention is to keep everything as proprietary as possible.
A strong framework being pushed from within Linux development itself might
mitigate this somewhat. Anyone have any thoughts on this?

Steve

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:15 EST