Messages in this thread | | | Date | Mon, 17 Jan 2000 22:15:41 +0800 | From | Steve Underwood <> | Subject | Re: drivers/telephony and winmodems |
| |
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/
| |