At 11:34 PM 8/5/96 -0800, you wrote:
What is unclear, however, is WHY they "had to" build a card that couldn't do full-duplex. I mean, would there have been a problem implementing that? Or was this just another one of those stupid design decisions which could have been easily fixed if it had been realized in time?
1) Costs money - especially critical if you're trying to either - get a new product accepted by the market (when they were becoming popular) or - compete in a me-too market (after they became popular and costs came way down.) 2) DSPs tend to be really tight on resources, especially RAM, which you need to do multiple programs at once. $5-10 DSPs are especially tight. They're starting to come with mini operating systems. 3) They probably didn't think of Internet Telephony as a market - They were PC folks, and while _we_ all knew about the Internet, it was probably 1/4 as big as now and earlier on the hype curve - It's only been recently that soundcards have been ubiquitous enough for people to assume they're there for a product like Internet phone - 28.8 modems are fast enough. 14.4 are marginal. 9.6 is _really_ marginal. 4) Most of their market wants other things - MIDI, game noises, talking applications, occasional recording and sound processing. Voice crunching is mostly used for answering machines and fancy voice-response telephony units "Press 1 if you want to Press 2."
It also has the advantage that the data is being moved through your CPU, so encryption is an easy add-on, rather than having one combined modem/voiceblaster card which doesn't have any hooks for crypto or other processing. Well, I assume that if implemented as a new type of modem card, the processor can be used to do the data transfer.
If you're doing the voice crunching and A/D conversion and telephony all on the modem card, with everything tightly integrated to fit in your tiny cache, why put in hooks for the processor to intervene?
Given that the "3KHz" is almost universally transmitted over 64kbps digital channels, there's really no point in pushing past 33.6 with analog-based coding; better to just do ISDN.
The local phonecos still want to overcharge for ISDN, however. Major bigtime problem. ISDN looked great back in about 1980 when the fastest common modem was 300 baud, but it's lost much of its lustre competing against 33.6 kbps. Maybe if ISDN were available at a premium of $5 per month or so...
Depends on the telco. Here in PacBell's fiefdom, home ISDN costs only a bit more than two voice lines, and you get two lines out of it. Local calls are a penny or four a minute daytime, free at night. This may change soon - the telco is appalled to find out that computer people think "it's free at night" means "it's free at night" :-) There's getting to be enough ISDN support that an ISDN-based phone program might find some market - especially if it can use higher sampling rates and ADPCM compression to get better sound out of 56-64 kbps than a regular phone can, and maybe you could support a shared-whiteboard program as well. Still need to do something about echo control, though. However, I wouldn't recommend writing a free encrypted ISDN telephone program, though - you wouldn't be able to export that on the Internet. But a phone program that lets users plug in their own algorithms for echo control, with an API that supports exchanging parameters - now _that_ would be a phone program. # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts@ix.netcom.com # <A HREF="http://idiom.com/~wcs"> Defuse Authority!