From owner-freebsd-multimedia Mon Oct 7 12:26:58 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA20440 for multimedia-outgoing; Mon, 7 Oct 1996 12:26:58 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA20434 for ; Mon, 7 Oct 1996 12:26:56 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.7.6/8.7.3) with ESMTP id MAA00474; Mon, 7 Oct 1996 12:26:52 -0700 (PDT) Message-Id: <199610071926.MAA00474@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Denis DeLaRoca 825-4580 (310) cc: multimedia@FREEBSD.ORG Subject: GUS and VAT (Re: RealAudio on FreeBSD ) In-reply-to: Your message of "Mon, 07 Oct 1996 08:22:00 PDT." <199610071522.IAA05049@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 07 Oct 1996 12:26:52 -0700 From: Amancio Hasty Sender: owner-multimedia@FREEBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >From The Desk Of Denis DeLaRoca 825-4580 : > On Sun, 06 Oct 1996 14:50:10 -0700, > Amancio Hasty 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 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