[lkml]   [1999]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: question about sblive and linux

> So, what we end up having to do is a lot of work to emulate and trap these I/O
> ranges, and to respond to the IRQ/DMA requests all the while maintaining the
None of this emulation will be necessary under linux. Because linux programs,
even games, use the device drivers exclusively.
I hope a linux driver will be written to use the chip as-is, and not
do any sort of useless emulation that only waste CPU time.

Emulation may be useful for those who run dos games with DOSEMU/WINE, but
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
> 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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:49    [W:3.364 / U:0.008 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site