Skip site navigation (1)Skip section navigation (2)
Date:         Mon, 07 Oct 96 08:22 PDT
From:      Denis DeLaRoca (310) 825-4580        <CSP1DWD@MVS.OAC.UCLA.EDU>
To:        multimedia@FREEBSD.ORG
Subject:   Re: Re: RealAudio on FreeBSD
Message-ID:  <199610071522.IAA05049@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
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
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610071522.IAA05049>