On Wed, 13 Jan 1999, Helge Hafting wrote:DOSemu does it's own emulation of sound hardware. You tell your
>> 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
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 balanceEveryone that I know of that buys a Super7 board (virtually
>> 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
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
>platforms like DOS, yes. No problem on linux as there is noVery true.
>such thing as "soundblaster compatibility" there.
>- Hardware backwards compatibility is mostly a non-issue,I would rephrase that as "We *WONT* be tied to a specific
> no programs ever depends on the hardware anyway. This because
> we don't want to be tied to a specific vendor.
>- Open source is appreciated. Open development is even better - you can have peopleThe linux community needs to be studied by any company that
> 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.
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.I agree 100%.
> 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,That is traditionally the way the whole kernel has been built,
> and release a beta as soon as that works. Then make new releases whenever
> a new feature (midi, mixer, ...) is completed.
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
Open-hardware is the next logical step. With projects like
Lets all support vendors that are open, and who support us, buy
Take care everyone,
Linux software galore: http://freshmeat.net
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.