Subject: Re: NetBSD /dev/audio
To: John Hawkinson <jhawk@panix.com>
From: George Michaelson <G.Michaelson@cc.uq.oz.au>
List: current-users
Date: 12/12/1994 08:48:45
  
  I looked at this briefly last week, and mycroft happened to be around; we
  determined that there were some timing interactions between vat and the
  sb driver -- the attached patch allowed to vat to work partially.
  
  --
  John Hawkinson
  jhawk@panix.com
  
  *** 1.1	1994/12/06 22:13:45
  --- sb.c	1994/12/06 22:14:11
  ***************
  *** 275,283 ****
    	register int i;
    
    	for (i = 100; --i >= 0; ) {
  ! 		if ((inb(iobase + SBP_DSP_WSTAT) & SB_DSP_BUSY) != 0)
    			continue;
    		outb(iobase + SBP_DSP_WRITE, v);
    		return 0;
    	}
    	++sberr.wdsp;
  --- 275,286 ----
    	register int i;
    
    	for (i = 100; --i >= 0; ) {
  ! 		u_char x = inb(iobase + SBP_DSP_WSTAT);
  ! 		delay(20);
  ! 		if ((x & SB_DSP_BUSY) != 0)
    			continue;
    		outb(iobase + SBP_DSP_WRITE, v);
  + 		delay(20);
    		return 0;
    	}

There are a couple of things I'd like to note: 

(1)	the version of the code Steve McCanne used replaced the value in
	the for (i=100 with a #DEFINE NPOLL, the value of which was 3000
	for SBPro and cards being driven in compatible forms. I think
	we're being bitten by version-itis again here!

(2)	Even if the effects of nested delay() calls is different to a
	forloop of longer duration, this kind of wired-in value is going
	to be bogus on different architectures, so parameterizing the
	delays makes sense to me anyway.

I'll try this out when I get a viable kernel back again, last time I
tried I has audio in from the network out to speaker just fine but
corrupted input back in from mike.

-George