Date: Tue, 08 Oct 1996 00:34:36 -0700 From: Amancio Hasty <hasty@rah.star-gate.com> To: Denis DeLaRoca 825-4580 (310) <CSP1DWD@MVS.OAC.UCLA.EDU> Cc: multimedia@FREEBSD.ORG Subject: Re: GUS and VAT (Re: RealAudio on FreeBSD ) Message-ID: <199610080734.AAA03637@rah.star-gate.com> In-Reply-To: Your message of "Mon, 07 Oct 1996 18:39:00 PDT." <199610080139.SAA02269@rah.star-gate.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610080734.AAA03637>