[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:0.023 / U:12.512 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site