Re: question about sblive and linux

Mike A. Harris (mharris@ican.net)
Sat, 16 Jan 1999 14:48:37 -0500 (EST)


On Wed, 13 Jan 1999, Helge Hafting wrote:

>> 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
>certainly
>not for any of the many linux programs that use sound. Such emulation
>should be part of those packages, not a driver.

DOSemu does it's own emulation of sound hardware. You tell your
programs that you have an SB16 regardless of what you really do
have. Unfortunately, I've yet to hear a peep out of my soundcard
in DOSemu from both the DSP and the FM chip. I've tried every
DOSemu release, and it's no-go.

>> 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.

Everyone that I know of that buys a Super7 board (virtually
everyone) gets VIA chipsets. I'll likely be getting one myself
this year too for a K6-3-400 upgrade.

Has anyone played around with Turtle Beach cards? I'm thinking
of getting one, and I'm curious as to which models are
recommended. Legacy compatibility is not important, since I have
an SB16 that will be staying in the machine anyways. I'm looking
for something that does full duplex at 16bit/44.1khz both
directions. Perhaps something with even more channels as well.
Wavetable support of some kind too, high quality.

>platforms like DOS, yes. No problem on linux as there is no
>such thing as "soundblaster compatibility" there.

Very true.

>- 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.

I would rephrase that as "We *WONT* be tied to a specific
vendor".

>- 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.

The linux community needs to be studied by any company that
hasn't allready done it. That way they can learn about us all,
and how we work, how we expect things. Any other way will likely
be met with opposition and lack of interest. They should also
hop over to http://www.opensource.org and read *EVERYTHING*
there, especially Eric S. Raymond's excellent papers "The
Cathedral and the Bazaar", and "Homesteading the Noosphere".

>- Writing a driver supporting every feature takes time - this is understood.
> But there is no reason for delaying the release until that.

I agree 100%.

> 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.

That is traditionally the way the whole kernel has been built,
no? All drivers start somewhere. Once part of a piece of
hardware functions, it is immediately useful. Putting out a
driver that supports part of a piece of hardware, while you
continue to develop, means that it is being actively tested by
the people with that hardware. If there are bugs, they will be
found, and bug reports will start coming in. If the source code
is available, then patches to fix the bugs will also come piling
in. If the specs are available, then patches for the rest of the
hardware's features will start pouring in as well.

Open-source and Open-spec are the wave of the future. It started
back in the 80's, but until just recently it hadn't taken its
foothold. It is the only way to go now though. Within the next
year or so, ALL companies will realize this, or will flop.

Open-hardware is the next logical step. With projects like
open-bios and open-everything starting up, it's only a matter of
time.

Lets all support vendors that are open, and who support us, buy
purchasing and recommending their products. I know I do.

Take care everyone,
TTYL

--
Mike A. Harris  -  Computer Consultant  -  Linux advocate

Linux software galore: http://freshmeat.net

- 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/