Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!spool.mu.edu!newspump.sol.net!ddsw1!news.mcs.net!in-news.erinet.com!news.izzy.net!news1.good.net!news.good.net!news.magicnet.net!feed1.news.erols.com!hunter.premier.net!news.mathworks.com!news-peer.gsl.net!news.gsl.net!portc01.blue.aol.com!newsstand.cit.cornell.edu!news.acsu.buffalo.edu!news.drenet.dnd.ca!crc-news.doc.ca!nott!bcarh189.bnr.ca!bmerhc5e.bnr.ca!news From: Andrew Atrens <atrens@nortel.ca> Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: Soundblaster16 woes... Date: Fri, 25 Oct 1996 10:11:03 -0400 Organization: Nortel Technology (formerly Bell Northern Research) Lines: 96 Message-ID: <3270CA77.44C5@nortel.ca> References: <326F8A85.519D@bnr.ca> NNTP-Posting-Host: bmerh278.bnr.ca Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0 (X11; I; HP-UX A.09.05 9000/712) Hi again folks, This is an update on my last post -- I've gotten a bit further, but still not to the bottom of the problem... There appears to be some kernel breakage here. Perhaps this is a known problem with the October 10th SNAP? Any help/suggestions are always appreciated :) . Cheers, Andrew ( opinions are mine, not Nortel's ) --- > The Symptoms > ============ > > Using rplay, vplay, xanim, cat, and a few others get the following: > > 1. Short sound clips sound fine, although under certain conditions if > I play a clip 2 seconds in length, then a clip 1 second in length > the 1 second clip will be followed by 'junk' sounds left over from > playing the first clip. For example: > > First clip: "Doh!" > Second clip: "Meep Meep!" > First clip played a second time: "Doh!Meep!" This happens following an 'DMA timed out' error. The code appears to use a static buffer for data and isn't properly flushing it following one of these errors. > > 2. After playing any clip, even using 'cat >>/dev/dsp', there is a > two second pause following the clip ( 'cat' just hangs there for > two seconds ). Rplay diagnostics indicate that rplayd is trying > to close the device; and apparently this takes 2 seconds. This > makes it impossible to play clips back to back. Seem to have repaired this for non-blocking tools like rplayd. 'cat', which is blocking, will still hang for a couple of seconds. > > 3. Playing a clip longer than two seconds just doesn't seem to work > at all. If I'm lucky I get the 2 seconds of mangled output, > followed > by silence. If I'm using rplay then there are no errors. If I try > 'cat >>/dev/dsp' I often get a (repeated) kernel message: > "DMA timed out, possible IRQ/DRQ conflict" > I would believe this message if the darn thing didn't work so well > unders Windows 3.1 ! To characterize this one a bit better, it appears that calls to DMA_getwrbuffer ( get a DMA write buffer ) are failing. If the device has been opened as 'non-blocking' the data gets pitched and the call silently fails. If the device (/dev/dsp) is opened in 'blocking' mode then the 'DMA timed out error' starts to appear; following one of these errors the DMA channel get reset, closed and re-opened again. This appears to clear the blockage temporarily ( another 1 second or so of output may be heard ), but then we run out of DMA write buffers again and the error reoccurs. The interesting thing is that though the DMA write buffers are being processed properly ( the sounds are heard ), for some reason they are: i) not being freed correctly. ii) assumed to be in use, when really they have been freed. > > What I've done > ============== > > Looked at the differences between Voxware 3.01 and the kernel sources > which I believe are Voxware 2.9, looking for changes/enhancements in > the SB drivers and the DMA code. > > Experimented, to a degree with folding in some of these changes. Also > played with the DMA buffer sizes in the driver. > > Modified the rplay port such that it uses /dev/dsp instead of > /dev/audio ( hey, why not ), I did this by folding in code from the > linux-specific audio stuff in the package. Seems to work okay. Tried patching in the 2.1.5 sound stuff into my kernel. This code appears to exhibit similar symptoms. Stripped the kernel down to 'bare bones', removing lpt0 and others. In BIOS, disabled my printer device. Enabled debugging messages in the driver, and added a few of my own. Tonight I'm going to pull my NE2000 clone card, try the SB in different slots, and do other basic tests along those lines.