Date: Mon, 07 Oct 1996 12:26:52 -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: GUS and VAT (Re: RealAudio on FreeBSD ) Message-ID: <199610071926.MAA00474@rah.star-gate.com> In-Reply-To: Your message of "Mon, 07 Oct 1996 08:22:00 PDT." <199610071522.IAA05049@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>From The Desk Of Denis DeLaRoca 825-4580 :
> On Sun, 06 Oct 1996 14:50:10 -0700,
> Amancio Hasty <hasty@RAH.STAR-GATE.COM> said:
>
> > Wait a little longer , I had a problem over here with my version of
> > vat which was triggered by the sound driver. So far vat seems to work
> > okay. For instance, I was listening to CBC news last night. The only
> > gotcha is that sometimes vat gets behind and the sound gets distorted.
> > It is a little difficult to fix because the sound buffering is setup
> > for 20ms 8)
>
> The way I understand it, the 20ms is a compromise figure to minimize
> system buffering to reduce latency vrs the need to have enough buffer
> to maintain playout during processing and scheduling delays -- both
> sender and receiver must agree on it as Vat uses audio read comple-
> tions as a clock for issuing audio writes. Since audio packets from
> the net may arrive late, and even out of order, Vat also keeps a playout
> buffer whose playout-point is adjusted typically on a per talk-spur
> basis -- this way net delays and even sender/receiver clock differences
> can be smoothed.
>
> 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 20 delta 0 block
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 20 delta 0 block
write msec 20 delta 0 block
write msec 20 delta 0 block
write msec 20 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
The "msec <value> delta" is the time it takes vat to write a packet to the
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
sound driver failing to deliver notification of a read on time
or vat failing to write a sound packet at its scheduled time.
> Amancio, I am looking forward to the new sound driver. Right now,
> besides the distorsion introduced by the sound hardware repeating
> previous sound samples I have seen the following problems:
The "feature" repeating of last sample has been turned off
on the gus 8)
> a) sliders don't seem to work
> b) the mike doesn't seem to work, the uv meter jumps off-scale
> when opening the mike.
Yes I am aware of the mixing and the next version of vat will fix that.
> c) when activating two Vats, when teh 2nd copy tries to grab
> the audio device I end up with a sleuth of error messages
>
> failed to set non-block mode for /dev/audio 9
This is a debugging aid . I will gladly take it out.
> d) when receiving audio with vat I keep seeing error mesages
>
> isa_dmastart: dma channel # busy
This is a bogus printf from isa.c just comment the printf. It should
never have been there to begin with except as a debugging aid.
Cheers,
Amancio
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610071926.MAA00474>