Most of the problems with earlier versions of the driver should
be fixed in this one; please report errors to me so I can iron out
any remaining bugs.  Depending on your system (how fast your processor
is, how heavily loaded you normally run, disk configuration, etc.),
you may need to adjust some parameters to get optimum performance.
If you start getting many "buffer overruns" (symptoms are an audible
click during playback, the "buffer overrun" LED at the top of the ds16
display becomes lit and remains lit) there are three things you can
do to give the convertor more "room":

1.  Change the interrupt priority of the IKON card in the back
of the Sun.  This involves changing two jumpers on the IKON card,
the INT jumper and the INT ACK jumper.  If you do this, I suggest 
setting the interrupt priority of the card to 6.  You will also
need to change the entry for the ai device in your configuration
file (in /usr/sys/conf) so that the priority matches the priority
you set for the card.  It will probably be the last line in the file.

2.  Change the number of buffers allocated for sample gathering from disk.
In the file aivar.h, there is a #define NUMBUFS 7 (line 39). This can
be safely increased -- it controls how much "reserve" the driver has
when disking becomes intense (i.e. many other processes competing for
disk resources).  It should be increased in increments of 3 (10, 13, 16...)
for proper functioning.

3.  The last thing you can do is to change the processor priority for
a critical section of the driver.  Lines 639 and 647 in the ai.c file
(near the "loop:" label in the aiioctl function, case AIO_GO of
the switch) contain "spl4()" functions.  These can be changed to "spl5()"
to insure that the driver will be serviced very quickly.  Use this
only as a last resort, however, because setting the processor priority
that high will interfere with your system clock and you will begin
to lose time.  I also have not done extensive testing with the driver
like this, so I don't know what other problems this may cause.

These solutions should be tried in the above order.


There are two bugs I know of with this version of the driver (and
associated programs) -- one is a bug in the driver and one is a bug in
the sfhedit program for editing soudfile header programs.  The driver
bug has to do with the ending of files during "play"  -- occasionally
the last 5-6k of the last buffer doesn't get cleared for some reason;
symptoms is that you may hear a "pip" or "bleep" at the end of a play.  I'm
working on a solution; the change won't be a major one, just some stupidity
about flushing the kernel buffers through the ds16.  The temporary
solution to this problem is to append some silence (zeros) to
the end of the soundfile.

The "sfhedit" bug occurs when you try to edit a soundfile that you have 
recorded and has no maximum amplitude listed -- the program obnoxiously
terminates by dumping core.  The solution is to run the "sndpeak"
program on the digitized soundfile; this will fill in the maximum
amplitude entry.

Some final observations:  The driver doesn't understand about disk
fragments -- since we aren't reading or writing  the last block of a 
soundfile this probably won't be noticed, but it's a good idea to
make the blocksize == fragmentsize on the disk partition you
are using for soundfiles (blksize MUST be 8192, normal for Sun Unix).
I've also only used this on SMD-type disks, I'm not sure how well
SCSI disks will behave with the disking code used.  You will also notice
that this version of the driver is a little more cpu-intensive than previous
versions, other users may notice "vi" slowing down a bit during conversion,
etc.  Oh well, can't have everything!

Good Luck -- Brad Garton.