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