For what its worth, my system uses an Adaptec SCSI PCI card, without problems
(using original release version of Windows 95). However, interestingly, because
of the need to juggle cards around, I did install the Csound card by itself, and
only when I found it was unreliable as a full MMedia card, did I reinstall my
SoundBlaster as well. Given the flaming hoops Plug-n-Play must leap through to
arbitrate betweeen all these systems, some order-sensitive behaviour doesn't
seem unexpected!

Re memory:
I have no confidence that even 64MB of ram would guarantee solid reloading of
sample data. I use the memory monitor from the Richter book, from time to time,
and Windows readily fills up all memory, given any oportunity. If I have VC++
running (VERY memory hungry), and a large soundfile cached in memory also (I am
quite impressed how much Windows does this, with quite large soundfiles), I
would expect the 64MB to be fully taken up. In my view, there are only two
reliable options - lock the sample memory when allocated by the driver, or admit
defeat and add the necessary DRAM to the card. I think manufacturers may well
look more interestedly at the card when redesigned this way.

Richard Dobson

Vercoe, Scotty wrote:
> 
> But, seriously, I have had some notices (which I have now verified)
> about conflicts with Adaptec SCSI cards.  I think both PCI and ISA SCSI
> cards may be a problem.  Someone said they use an ultra-wide SCSI card
> without conflicts, but I'm not sure which make it was.
> 
> Because samples are stored on the host memory, we usually use 64Meg RAM.
> There are some issues in the allocation which we are tracking down.
> 
> Best regards,
> Scotty Vercoe
> Extended Csound Applications Consultant
> Analog Devices Software & Systems Technology Division
> Tel: (781) 461-3569       FAX: (781) 461-4291
> Support: Csound.support@analog.com

>Re memory:
>I have no confidence that even 64MB of ram would guarantee solid reloading of
>sample data. I use the memory monitor from the Richter book, from time to
time,
>and Windows readily fills up all memory, given any oportunity. If I have VC++
>running (VERY memory hungry), and a large soundfile cached in memory also
(I am
>quite impressed how much Windows does this, with quite large soundfiles), I
>would expect the 64MB to be fully taken up. In my view, there are only two
>reliable options - lock the sample memory when allocated by the driver, or
admit
>defeat and add the necessary DRAM to the card. I think manufacturers may well
>look more interestedly at the card when redesigned this way.
>
>Richard Dobson
>
I'd like to chime in here to add that, when and if ADI does consider a
redesign of their developer board, I strongly support the onboard DRAM
option for all the reasons Richard D. raised and others I have mentioned in
the past. There are other changes that would be desireable, as well - such
as direct host access to the MIDI and Audio ports, so I urge that ADI gets
lots of developer feedback if it considers a redesign.

Russell Pinkston

Russell F. Pinkston, D. M. A.
Associate Professor of Composition
Director, Electronic Music Studios
School of Music
University of Texas
Austin, TX 78712