Date: Tue, 08 Oct 1996 02:02:34 -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: <199610080902.CAA04941@rah.star-gate.com> In-Reply-To: Your message of "Mon, 07 Oct 1996 18:39:00 PDT." <199610080140.SAA18271@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
If you were wondering about the 160ms gap here is more info:
After a minute or so of playing....
write msec 20 delta 0 block
read msec 20
write msec 20 delta 0 block
read msec 20
write msec 20 delta 0 block
read msec 20
read msec 20
read msec 20
read msec 20
read msec 20
read msec 20
read msec 20
read msec 20
read msec 20
read msec 20
read msec 20
read msec 20
read msec 20
read msec 20
read msec 20
read msec 20
write msec 320 delta 0 block
write msec 0 delta 0 block
read msec 20
write msec 20 delta 0 block
read msec 20
write msec 20 delta 0 block
read msec 20
write msec 20 delta 0 block
read msec 20
The 320 millisecond gap could be attributed to packets out of order or
missing packets. During that time NO packets where delivered to the
sound driver .
Here is the output of a fairly steady state :
write msec 20 delta 0 block
read msec 20
write msec 20 delta 0 block
read msec 20
write msec 20 delta 0 block
read msec 20
write msec 20 delta 0 block
read msec 20
write msec 20 delta 0 block
read msec 20
write msec 20 delta 0 block
read msec 20
write msec 20 delta 0 block
read msec 20
write msec 20 delta 0 block
read msec 20
write msec 20 delta 0 block
read msec 20
write msec 20 delta 0 block
read msec 20
write msec 20 delta 0 block
read msec 20
write msec 20 delta 0 block
read msec 20
write msec 20 delta 0 block
read msec 20
write msec 20 delta 0 block
read msec 20
write msec 20 delta 0 block
read msec 20
write msec 20 delta 0 block
read msec 20
write msec 20 delta 0 block
read msec 20
write msec 20 delta 0 block
read msec 20
write msec 20 delta 0 block
Now a little bit about the printfs . Basically,
"write msec ..." states the delta time it took vat to write a sound packet
to the sound driver.
"read msec .." states the delta time that the sound driver takes to read
160 bytes @ 8khz and notifies vat.
At the very least the sound driver is not way off and it is doing its job.
In audio.cc:
void Audio::dispatch(int)
{
int delta,msec;
struct timeval now;
gettimeofday(&now, NULL);
delta = ((1000 * now.tv_sec) + now.tv_usec / 1000) -
((1000 * read_delta.tv_sec) + read_delta.tv_usec / 1000);
printf(" read msec %d \n", delta);
read_delta = now;
while (FrameReady())
handler_->audio_handle();
}
----
At the tail of VoxWare::write (thats the routine which vat calls
to write a sound packet )
gettimeofday(&now, NULL);
delta = ((1000 * now.tv_sec) + now.tv_usec / 1000) -
((1000 * write_delta.tv_sec) + write_delta.tv_usec / 1000);
msec = ((1000 * now.tv_sec) + now.tv_usec / 1000) -
((1000 * write_last.tv_sec) + write_last.tv_usec / 1000);
printf("write msec %d delta %d block \n", msec, delta, block_sound);
write_last = now;
-------
Next step is to test vat with my other local machine which I have
to re-install FreeBSD .
Enjoy,
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.
>
> 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?199610080902.CAA04941>