Re: proliferation of voicesystems

At 15:38 8/27/95, Thomas Grant Edwards wrote:
>On Sun, 27 Aug 1995, Tatu Ylonen wrote:
>
>> Maybe someone could start writing an internet draft about "encrypted
>> voice transmission on the internet".  It should address several
>> issues:
>>   - compression methods, sampling rate differencies, encoding methods
>
>BTW - does anyone actually know what the voice compression is in
>PGPfone?

GSM lite and I think CELP. PGPFone has some serious problems with the
variable latencies of real life connections. These problems will not go
away until PGPFone makes the shift to APIs that are designed to deal with
such problems, such as QuickTime conferencing. I hope PRZ will realize
this.


-- Lucky Green <mailto:shamrock@netcom.com>
   PGP encrypted mail preferred.

Lucky Green writes:
> >BTW - does anyone actually know what the voice compression is in
> >PGPfone?
> 
> GSM lite and I think CELP. PGPFone has some serious problems with the
> variable latencies of real life connections. These problems will not go
> away until PGPFone makes the shift to APIs that are designed to deal with
> such problems, such as QuickTime conferencing. I hope PRZ will realize
> this.

  And Windows95/NT has a Audio Compression Manager which comes with
GSM and TrueSpeech compression drivers. 

  The problem is, what will be done for the Unix users? A standard
audio API is sorely missing in the unix world (NetWork Audio 
System and AudioFile aren't solutions)

-Ray

Ray Cromwell writes:
>   The problem is, what will be done for the Unix users? A standard
> audio API is sorely missing in the unix world (NetWork Audio 
> System and AudioFile aren't solutions)

It depends on what you mean by an API. If you are just talking about
driver interfacing there are de facto standards at this point --
basically everyone has been adopting the sun /dev/audio ioctls. 

.pm

> 
> 
> Ray Cromwell writes:
> >   The problem is, what will be done for the Unix users? A standard
> > audio API is sorely missing in the unix world (NetWork Audio 
> > System and AudioFile aren't solutions)
> 
> It depends on what you mean by an API. If you are just talking about
> driver interfacing there are de facto standards at this point --
> basically everyone has been adopting the sun /dev/audio ioctls. 

  That's too low-level to deal with the proliferation of PC sound systems,
especially since even non-intel workstations are adopting PCi buses.
If I recall, /dev/audio relies on u-law/a-law encoding. That's only one
component of a higher level audio system. That's like having a
/dev/svga but no Motif library. Furthermore, a /dev/audio like
interface doesn't admit good hardware acceleration, such as if you
had to play an MPEG layerIII audio, but your sound card had a DSP.

-Ray