Date: Thu, 23 May 1996 08:42:57 -0400 From: "Louis A. Mamakos" <louie@TransSys.COM> To: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Cc: multimedia@FreeBSD.org Subject: Re: Problems with the guspnp1 driver? Message-ID: <199605231242.IAA01067@whizzo.transsys.com> In-Reply-To: Your message of "Wed, 22 May 1996 17:45:36 PDT." <199605230045.RAA05154@rah.star-gate.com> References: <199605230045.RAA05154@rah.star-gate.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605231242.IAA01067>