Emulation may be useful for those who run dos games with DOSEMU/WINE, but
certainly
not for any of the many linux programs that use sound. Such emulation
should be part of those packages, not a driver.
> proper timing characteristics of the PCI bus. It is a very delicate balance
> between the driver and the chip in-order for this to function properly. However
> this is a requirement of our because we are makers we have to maintain "Legacy"
> compatibility. To games, and in fact to most of the test programs available
> this works perfectly. We have found a couple of instances where the support
> does not work properly, these are primarily with VIA PCI chipsets.
Another reason for not using emulation then. Many linux machines use the VIA
chipset.
>
> Needless to say Sound Blaster wouldn't work on non-Intel platforms anyway,
> because the I/O ranges would not be applicable in an Alpha, CISC or RICS
> processors. This is a fundamental problem that needs to be looked at in any
> driver the Creative develops, it is very difficult for Creative to walk away
> from "Sound Blaster Compatibility".
Difficult on broken platforms like DOS, yes. No problem on linux as there
is no such thing as "soundblaster compatibility" there.
Linux users appreciate the effort to make a good driver. In order to achieve this
goal, be aware of some differences in the linux world:
- Hardware backwards compatibility is mostly a non-issue,
no programs ever depends on the hardware anyway. This because we don't want to be
tied to a specific vendor.
- A hardware vendor may succeed on merit. Good hardware, well-working efficient
drivers that arrives on time is the way to go.
- Open source is appreciated. Open development is even better - you can have people
sending in patches for bugfixes and performance enhancements.
You can of course be the central authority on your own driver - but accepting
improvements from outside is generally a good thing.
- Writing a driver supporting every feature takes time - this is understood.
But there is no reason for delaying the release until that.
I recommend going for the basic /dev/dsp (D/A A/D converters) first,
and release a beta as soon as that works. Then make new releases whenever
a new feature (midi, mixer, ...) is completed.
Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/