From owner-freebsd-multimedia Mon Oct 7 08:22:11 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA05059 for multimedia-outgoing; Mon, 7 Oct 1996 08:22:11 -0700 (PDT) Received: from MVS.OAC.UCLA.EDU (mvs.oac.ucla.edu [164.67.200.200]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA05049 for ; Mon, 7 Oct 1996 08:22:07 -0700 (PDT) Message-Id: <199610071522.IAA05049@freefall.freebsd.org> Received: from UCLAMVS.BITNET by MVS.OAC.UCLA.EDU (IBM MVS SMTP V2R2.1) with BSMTP id 4186; Mon, 07 Oct 96 08:22:40 PST Date: Mon, 07 Oct 96 08:22 PDT To: multimedia@FREEBSD.ORG From: Denis DeLaRoca (310) 825-4580 Subject: Re: Re: RealAudio on FreeBSD Sender: owner-multimedia@FREEBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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 should show as a silence gap on the audio stream. If the receiver play- out point increases linearly until it hits max, packets are dropped resulting in sound clipping. I don't know if Vat currently tries to handle this situation by estimating both the playout point and trend in the estimate to implement selective packet discards in order to achieve steady state -- though the resulting sound might not be perfect. I think the observed sound distortion here, gus sound driver, is due to problems with the sound driver and little to do with the choice of 20ms audio buffers. I don't see this behaviour in say a Sun workstation where the same algorithms yield reasonably clear audio under similar network conditions with also full-duplex audio hardware. 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: 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. 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 d) when receiving audio with vat I keep seeing error mesages isa_dmastart: dma channel # busy -- Denis