On Sat, 19 Oct 2002 11:22:58 +1000 (EST), David Forrester wrote:

>
>I've had a look at the UniAud source, and there's lots of code to
>handle the Audigy. There doesn't seem to be anything to stop it or
>turn it off, so it should work. But, as the source is for the
>UNIAUD32.SYS, there may be something in UNIAUD16.SYS that's stopping
>it.

Since I sent this, I wrote out a list of the changes needed to get the
UniAud source to recognize extra chipsets. After did that, it I
realised that there is a spot in the driver that will stop the Audigy
from being used. The driver has a section that looks for supported
chipsets. The Audigy will pass this as it is included in with the
SBLive. But, there's another check that explicitly tests the PCI ids
of the supported devices before finalizing the it's initialization.
The id of the Audigy is not included in this.

If you tried to load the driver with an Audigy card, this is what I'd
expect to see (based on what I see if I setup similar conditions for my
soundcard):

- Copyright message displayed for 16 and 32 bit drivers
- Message about finding a "Sound Blaster Audigy" with the resources
used (probably memory addresses and IRQ).
- Then a message "Initialization failed"
- When you look in Hardware Manager, there should be an entry for "OS/2
Universal Audio Driver" without any resources.

I think this is what will happen, but, there may be some trickery in
the EMU10K2 that allows it to be loaded correctly without any changes
to UNIAUD32.SYS.

If someone wants to try this, and don't have the ability to build the
driver, tell me, and I'll make the changes and build it. I would
really like to see if we can get any card going that is not in the
supported list from Innotek.

And if anyone from Innotek wants to pop in and tell me I'm wrong, and
how I'm, I'd be happy to hear it :)

--
David Forrester
davidfor@...
http://www.os2world.com/djfos2/