From owner-freebsd-multimedia Mon Oct 7 18:40:21 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA18278 for multimedia-outgoing; Mon, 7 Oct 1996 18:40:21 -0700 (PDT) Received: from MVS.OAC.UCLA.EDU (mvs.oac.ucla.edu [164.67.200.200]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA18271 for ; Mon, 7 Oct 1996 18:40:18 -0700 (PDT) Message-Id: <199610080140.SAA18271@freefall.freebsd.org> Received: from UCLAMVS.BITNET by MVS.OAC.UCLA.EDU (IBM MVS SMTP V2R2.1) with BSMTP id 4917; Mon, 07 Oct 96 18:40:20 PST Date: Mon, 07 Oct 96 18:39 PDT To: Amancio Hasty From: Denis DeLaRoca (310) 825-4580 Subject: Re: GUS and VAT (Re: RealAudio on FreeBSD ) CC: multimedia@FREEBSD.ORG Sender: owner-multimedia@FREEBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 07 Oct 1996 12:26:52 -0700, Amancio Hasty 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. 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. -- Denis