From owner-freebsd-hardware  Thu Aug 22 13:25:14 1996
Return-Path: owner-hardware
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id NAA13683
          for hardware-outgoing; Thu, 22 Aug 1996 13:25:14 -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 NAA13626;
          Thu, 22 Aug 1996 13:25:02 -0700 (PDT)
Message-Id: <199608222025.NAA13626@freefall.freebsd.org>
Received: from UCLAMVS.BITNET by MVS.OAC.UCLA.EDU (IBM MVS SMTP V2R2.1)
   with BSMTP id 2910; Thu, 22 Aug 96 13:25:32 PST
Date:    Thu, 22 Aug 96 13:24 PDT
To: multimedia@FREEBSD.ORG
From: Denis DeLaRoca (310) 825-4580        <CSP1DWD@MVS.OAC.UCLA.EDU>
Subject: Vat 4.0b2 and GUS Driver
CC: hardware@FREEBSD.ORG
Sender: owner-hardware@FREEBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

I am running Vat 4.0b2 (compiled with the voxware audio code interface)
and the beta Gravis Ultrasound pro driver. By and large it works.
Often though, it seems that 2 or more samples are merged on playback...
but worst still, all of a sudden the last audio chunk is replayed
repeatedly for something like 3-5 seconds. When this happens, Vat's
UV meter freezes.  This repeated-playback problem does occur quite
often.

Is anybody observing similar problems? At the moment I don't know
if Vat with the Voxware audio code is supposed to work asis with
the GUS driver. Amancio Hasty who developed the driver reported
running ok with Vat 4.0b1 but his FTP site is down and I am unable
to verify wether he had modified Vat or not. Vat's audio sliders
for example, though selectable, appear non-functional. Opening the
mike for speaking makes Vat's input VU meter hit its maximum and
it was impossible to adjust the input level. Both locally compiled
versions of Vat, b1 and b2, give the above problems.

My GUS hardware configuration appears ok. I noticed "isa_dmastart:
channel 3 busy" messages when starting Vat. But that appears to be an
artifact that when Vat quits the list of busy dma channels in the
kernel is not updated. At any rate isa_dmastart() just disregards busy
dma channels after issuing the warning message.

I am running on a fairly slow 486 system but I think the problems
are more in the interfacing between vat and the GUS driver and/or
plain problems with the GUS beta driver.

Anybody can help?

-- Denis