From owner-freebsd-multimedia  Tue Oct  8 00:34:40 1996
Return-Path: owner-multimedia
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id AAA03067
          for multimedia-outgoing; Tue, 8 Oct 1996 00:34:40 -0700 (PDT)
Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA03059
          for <multimedia@FREEBSD.ORG>; Tue, 8 Oct 1996 00:34:38 -0700 (PDT)
Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.7.6/8.7.3) with ESMTP id AAA03637; Tue, 8 Oct 1996 00:34:37 -0700 (PDT)
Message-Id: <199610080734.AAA03637@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Denis DeLaRoca 825-4580 (310) <CSP1DWD@MVS.OAC.UCLA.EDU>
cc: multimedia@FREEBSD.ORG
Subject: Re: GUS and VAT (Re: RealAudio on FreeBSD ) 
In-reply-to: Your message of "Mon, 07 Oct 1996 18:39:00 PDT."
             <199610080139.SAA02269@rah.star-gate.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 08 Oct 1996 00:34:36 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>
Sender: owner-multimedia@FREEBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

The "write msec <value> delta ... message gets printed every time
vat writes to the audio device. My hacking has been restricted
to audio.cc.

	Amancio

>From The Desk Of Denis DeLaRoca 825-4580 :
> On Mon, 07 Oct 1996 12:26:52 -0700,
>    Amancio Hasty <hasty@RAH.STAR-GATE.COM> said:
> > > What does it mean when you say "vat gets behind and sound gets distor-
> > > ted"? If Vat gets behind because of a processing/scheduling delay that
> >
> > I mean this:
> > write  msec 20 delta  0 block
> > write  msec 20 delta  0 block
> > write  msec 40 delta  0 block
> > write  msec 20 delta  0 block
> > write  msec 20 delta  0 block
> > write  msec 160 delta  0 block
> >             ^^^^
> > write  msec 1 delta  0 block
> > write  msec 19 delta  0 block
> > write  msec 20 delta  0 block
> > write  msec 20 delta  0 block
> >
> > sound driver. If you noticed the highlighted 160 delta time means
> > that either the sound driver failed to deliver an asynch notification
> > of the read or vat failed to write a sound packet at its scheduled
> > 20ms interval. It should not be too hard to determine if its the
> 
> Humm? Do we know if those deltas of 40 and 160 are when Vat has been
> pre-empted? If it is pre-emption and no output queue has been built
> yet -- because this is the first time Vat is being pre-empted -- a
> silence gap will appear on the audio stream, but if the output queue
> has been built that is enough to keep audio output continuous. This is
> the self-clocking algorithm that Thomas just described.

Let me put it this way if vat does not write to the audio device
on the average every 20ms we will hear audio gaps now if the sound
is able to buffer and drain the buffers then that allow for slightly
more tolerance for vat to not write audio packets every 20ms.

> Are deltas above being computed by watching audio writes? Should be
> easy enough as you say to monitor asynch notifications and see if
> any are missing. If you haven't tinkered much with vat's code outside
> of the audio.cc a problem with delivery of read notifications by the
> sound driver sounds plausible.
> 


Well, I will let you guys know what the problem is tonite. Just got in
from work 8)


	Cheers,
	Amancio