From owner-freebsd-multimedia  Fri Jan 19 05:33:01 1996
Return-Path: owner-multimedia
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id FAA14544
          for multimedia-outgoing; Fri, 19 Jan 1996 05:33:01 -0800 (PST)
Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA14529
          for <multimedia@freebsd.org>; Fri, 19 Jan 1996 05:32:51 -0800 (PST)
Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id OAA00599; Fri, 19 Jan 1996 14:24:10 +0100
From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Message-Id: <199601191324.OAA00599@labinfo.iet.unipi.it>
Subject: Re: FreeBSD and VAT
To: hasty@rah.star-gate.com (Amancio Hasty Jr.)
Date: Fri, 19 Jan 1996 14:24:09 +0100 (MET)
Cc: james@miller.cs.uwm.edu, multimedia@freebsd.org,
        multimedia@rah.star-gate.com, tlehman@becky.acet.org, toml@mitre.org
In-Reply-To: <199601191147.DAA00952@rah.star-gate.com> from "Amancio Hasty Jr." at Jan 19, 96 03:47:25 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-multimedia@freebsd.org
Precedence: bulk

> rtpv2 does have a sequence number in the packets however we still have
> the problem that the sample may have been recorded within a given
> delta offset of the intended frequency . For instance, the card may
> oscillate and start recording a sample at 6000hz then pass that on
> to vat -- what do you then? Well Jim's solution is to depend on the

If the card claims 8KHz and it 25% off, it's badly broken and we
can't help much. If the card is within 2-3% of its nominal frequency,
as Jim suggested, that means a difference of 4-5 bytes per packet,
and I think we can easily compensate it.

Remember, the "clock" can only be the sender's sample rate.  It
may have jitter or be inaccurate, but it rules the speed at which
data come in.

> Well, we still have problems for cards which don't support ulaw. Probably
> there are more cards which support 16bit i/o output than ulaw. 
> You see ulaw for cards which don't have ulaw hardware compression 
> the driver does the conversion. For low end machines this begins to 
> strain the system.  

I don't get this. ulaw and alaw conversion it's a simple table lookup:

	for (i=0;i<segment_len;i++)
		linear_sample[i] = ulaw2linear[ulaw_sample[i]];

and requires just one table access per byte, i.e. one access per
125us. I doubt that the overhead can be more than 1%, even on a 386-16.

	Luigi
====================================================================
Luigi Rizzo                     Dip. di Ingegneria dell'Informazione
email: luigi@iet.unipi.it       Universita' di Pisa
tel: +39-50-568533              via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522              http://www.iet.unipi.it/~luigi/
====================================================================