From owner-freebsd-multimedia  Thu May 23 05:43:14 1996
Return-Path: owner-multimedia
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id FAA08926
          for multimedia-outgoing; Thu, 23 May 1996 05:43:14 -0700 (PDT)
Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id FAA08921
          for <multimedia@FreeBSD.org>; Thu, 23 May 1996 05:43:11 -0700 (PDT)
Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.7.5/8.7.3) with SMTP id IAA01067; Thu, 23 May 1996 08:42:58 -0400 (EDT)
Message-Id: <199605231242.IAA01067@whizzo.transsys.com>
X-Authentication-Warning: whizzo.transsys.com: Host localhost.transsys.com [127.0.0.1] didn't use HELO protocol
To: "Amancio Hasty Jr." <hasty@rah.star-gate.com>
cc: multimedia@FreeBSD.org
From: "Louis A. Mamakos" <louie@TransSys.COM>
Subject: Re: Problems with the guspnp1 driver? 
References: <199605230045.RAA05154@rah.star-gate.com> 
In-reply-to: Your message of "Wed, 22 May 1996 17:45:36 PDT."
             <199605230045.RAA05154@rah.star-gate.com> 
Date: Thu, 23 May 1996 08:42:57 -0400
Sender: owner-multimedia@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

I've got the guspnp1 driver compiled on two systems, and running on 1.
Both are FreeBSD-current systems and I had to patch the drivers to
make them go.  The system it's running on is a 486DX2/66 box, with a
GUS PnP w/1MB SIMM stick.  I had to install the early PNP code to
initialize the board, and then it started right up.

I've noticed some occasional problems with this version of the code,
and more so with the previous version where it will begin to repeat
the same 5 or 6 seconds of audio from vat until you close the device
(by exiting vat).  I *think* this may be better on the newer version,
but I haven't been running it long enough to tell.  I think that it's
related to the size of the write() being done, but that's just a
guess.

If you enable "lecture mode" in vat, the problem seems more likely to
happen.  If you 'cat /kernel > /dev/audio', then you can hose it up
pretty good.  In fact, in many cases, cat'ing a big file at
/dev/audio0 can utterly hang the machine, with no keyboard or mouse
activity requiring a hardware reset to recover.

On my second system, a P5/133, PCI, etc. also running -current, but
with a PNP BIOS, I had somewhat good luck with the previous version of
the gnspnp driver.  I put the new version on it last night, and to
test, tried 'audial 1234' while running the auvoxware sound server;
this caused the system to hang and then reset.  This used to work just
find (or at least failed to fail..).  It was late, so I backed up and
didn't try to do any further testing.

I've been using both versions to listen to the STS-77 multicast
traffic, and it seems to mostly be OK for that.  I have not been
successful using the microphone for input, but I've never actually had
a working microphone on the system at all, so there may be problems
unrelated to the software there.  I'll have to dig up another
microphone, and boot up windoz to try it out and make sure the
hardware is working.

louie