Date: Mon, 07 Oct 96 18:39 PDT From: Denis DeLaRoca (310) 825-4580 <CSP1DWD@MVS.OAC.UCLA.EDU> To: Amancio Hasty <hasty@RAH.STAR-GATE.COM> Cc: multimedia@FREEBSD.ORG Subject: Re: GUS and VAT (Re: RealAudio on FreeBSD ) Message-ID: <199610080140.SAA18271@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610080140.SAA18271>