question about sblive and linux
Jacob Hawley
take some months before it is ready. My suggestion to you is that if you want a
sound card that works I would suggest one of the ISA or Sound Blaster PCI
(formerly Ensoniq) products. These already have drivers available in the
kernel.
Jake
-----Original Message-----
From: Jakub Gwozdz <gwoz...@uci.agh.edu.pl>
To: jacob_...@msn.com <jacob_...@msn.com>
Date: Tuesday, January 12, 1999 8:39 AM
Subject: question about sblive and linux
>
>I would like to buy SBLive! or SBLive! Value, but i don't know if it will
>work with linux. Could you tell me (and/or inster this information on your
>web site), if SBLive will work on linux at least as SB16? Just until
>Creative write it's own libraries for ALSA?
>
>Best regards
>
>Jakub Gwozdz
>student of computer sciences at AGH, Krakow, Poland
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Jakub Gwozdz
> Currently the answer is no. We are actively developing a driver, but it will
> take some months before it is ready. My suggestion to you is that if you want a
> sound card that works I would suggest one of the ISA or Sound Blaster PCI
> (formerly Ensoniq) products. These already have drivers available in the
> kernel.
So... SBLive isn't compatible with SB16 (and earlier), is it?
Jakub Gwozdz
Greg Smart
The real question here is when you do release a driver, will
it allow Linux users to effectively use the SB Live hardware.
Creative's track record on windows NT drivers isn't that good.
If the register definitons and tech info were made public
(does this really threaten Creative's business?) then you will
find a lot of volunteers willing to get a driver out a lot faster. For
a product like a sound card, people will happily use an alternative
card if drivers are not available, so any delay costs. You should
also consider that there isn't much interest in adding proprietry
components to the linux kernel.
cheers
Greg Smart
> -----Original Message-----
> From: Jacob Hawley [SMTP:jha...@creaf.com]
> Sent: Wednesday, January 13, 1999 5:45 AM
> To: Jakub Gwozdz
> Cc: Linux (Kernel Reflector)
> Subject: Re: question about sblive and linux
>
> Currently the answer is no. We are actively developing a driver, but it
> will
> take some months before it is ready. My suggestion to you is that if you
> want a
> sound card that works I would suggest one of the ISA or Sound Blaster PCI
> (formerly Ensoniq) products. These already have drivers available in the
> kernel.
>
> Jake
> -----Original Message-----
> From: Jakub Gwozdz <gwoz...@uci.agh.edu.pl>
> To: jacob_...@msn.com <jacob_...@msn.com>
> Date: Tuesday, January 12, 1999 8:39 AM
> Subject: question about sblive and linux
>
>
> >
> >I would like to buy SBLive! or SBLive! Value, but i don't know if it will
> >work with linux. Could you tell me (and/or inster this information on
> your
> >web site), if SBLive will work on linux at least as SB16? Just until
> >Creative write it's own libraries for ALSA?
> >
> >Best regards
> >
> >Jakub Gwozdz
> >student of computer sciences at AGH, Krakow, Poland
> >
> >
> >
>
>
Jacob Hawley
be available short term features such as: WAV, Midi, PCM, Simple effects,
Stereo. This is mostly going to be a resource issue, for example to get where
we are today on Win9x (please it is just an example no flames) it took 6
engineers about 7 months. I expect that the development of the Linux driver
will be slow until we actually have a library / sourcecode to distribute.
I have literally hundreds of mails today regarding stability of the kernel. I
strongly believe that if the driver isn't architected right it could cause
problems. I understand that there is a strong following of capable engineers
for Linux and that they are willing to assist if not do the entire job. I think
that's great, but I also need to understand what the ramifications are. I would
hate to have a driver go out that was not capable of being extended to support
the full features of our EMU10K1 chip.
NT is mute because it is fundamentally broken, period. That any hardware works
on that OS is amazing.
Creative not unwilling to provide programming information, there simply isn't
any because it hasn't been written. We have almost never given this type of
information out, instead we have exposed functionality through API's (Windows
centric). So we have to work on writing the documents, sample source code, etc.
I am actively looking to hire engineers to help with this task, because I am
looking for a long term and permanent solution. I am looking to build a team
that will be able to support Linux on more than just one product, which includes
bug fixes, development tools, and feature enhancements.
regards,
Jake
Jacob Hawley
Short Answer:
Under DOS/Windows it is about 98% compatible.
Long Answer:
The PCI bus does not support ISA IRQ/DMA requests. In addition, the I/O ranges
that are typically used for Sound Blaster (220h - Basic Audio, 680h - WaveTable,
200h for Joystick) are not supported in the PCI config space.
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
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.
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".
Jake
-----Original Message-----
From: Jakub Gwozdz <gwoz...@uci.agh.edu.pl>
To: Jacob Hawley <jha...@creaf.com>
Cc: Linux (Kernel Reflector) <linux-...@vger.rutgers.edu>
Date: Tuesday, January 12, 1999 2:33 PM
Subject: Re: question about sblive and linux
>On Tue, 12 Jan 1999, Jacob Hawley wrote:
>
>> Currently the answer is no. We are actively developing a driver, but it will
>> take some months before it is ready. My suggestion to you is that if you
want a
>> sound card that works I would suggest one of the ISA or Sound Blaster PCI
>> (formerly Ensoniq) products. These already have drivers available in the
>> kernel.
>
>So... SBLive isn't compatible with SB16 (and earlier), is it?
>
>Jakub Gwozdz
>
>
Gerhard Mack
> To be honest I think that only a very, very small part of the functionality will
> be available short term features such as: WAV, Midi, PCM, Simple effects,
> Stereo. This is mostly going to be a resource issue, for example to get where
> we are today on Win9x (please it is just an example no flames) it took 6
> engineers about 7 months. I expect that the development of the Linux driver
> will be slow until we actually have a library / sourcecode to distribute.
It will be nice to be able to use this card from Linux.
[snip]
> NT is mute because it is fundamentally broken, period. That any hardware works
> on that OS is amazing.
> Creative not unwilling to provide programming information, there simply isn't
> any because it hasn't been written. We have almost never given this type of
> information out, instead we have exposed functionality through API's (Windows
> centric). So we have to work on writing the documents, sample source code, etc.
>
> I am actively looking to hire engineers to help with this task, because I am
> looking for a long term and permanent solution. I am looking to build a team
> that will be able to support Linux on more than just one product, which includes
> bug fixes, development tools, and feature enhancements.
Will the resulting code be released GPL? (gnu public license) And be
submitted for inclusion into the kernel ?
Your answer to that question will affect the caliber of people who reply
to your job offer.
Gerhard
As a computer I find your faith in technology amusing.
Helge Hafting
> 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
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.
> 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
Thomas Wouters
On Wed, Jan 13, 1999 at 10:05:26AM +0100, 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.
Nah. DOSemu, at least, emulates an SB16 card, by using the normal linux
sound interface (IIRC anyway). Perhaps it is/was possible to use the SB16
directly from inside DOSemu, bypassing the normal driver, but that'd be very
errorprone behaviour anyway. Not sure about WINE, but i dont see why one
would give direct access to soundcard hardware from inside DOSemu or WINE if
one could use the native linux drivers. Rather spend the effort writing a
linux driver for that sound card :)
> - 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.
It's worse than that... Linux needs to standardize 'advanced sound options'
some way, provide an API for it, which includes room for future crufty
soundfeatures. I believe there is work going on in that area, haven't been
reading my Freshmeat faithfully lately, due to lack of time :P
David Foster
>To be honest I think that only a very, very small part of the functionality
>will
>be available short term features such as: WAV, Midi, PCM, Simple effects,
>Stereo. This is mostly going to be a resource issue, for example to get where
>we are today on Win9x (please it is just an example no flames) it took 6
>engineers about 7 months. I expect that the development of the Linux driver
>will be slow until we actually have a library / sourcecode to distribute.
<snip>
>Creative not unwilling to provide programming information, there simply isn't
>any because it hasn't been written. We have almost never given this type of
>information out, instead we have exposed functionality through API's (Windows
>centric). So we have to work on writing the documents, sample source code,
>etc.
I think it would amaze you just how much making this an open source project
would help. And, as a hardware vendor, that wouldn't cut into sales at
all. I realize it's a different way of thinking, but instead of relying on
internal QC procedures, you'd have a lot of people on the Net poring over
the source looking for problems. And you'd basically gain free consulting
from the people who have written previous drivers for Linux, and know the
sound sub-system cold.
To be honest, if you go the familiar route of closed source, I can't
imagine many people buying the card for Linux. I, for one, would be very
hesitant to install a driver for which I didn't have source code. My main
concern would be that if Creative chose to discontinue Linux support, I'd
be stranded. If the source is open, I know that somebody will continue to
maintain it.
Open source would be a win-win situation for Creative here. Not only would
you gain the increased productivity of open source development, but you
would be surprised how many people will buy the card just to play with the
source code. After all, you aren't selling drivers, you're selling
hardware. And releasing the source and opening development can only result
in increased sales.
Linux market share is increasing rapidly and, as your interest shows, is
becoming a platform that hardware vendors need to consider. To be
successful in the Linux market, though, it's valuable to do things "the
Linux way", in the same way that it is necessary to do things "the
Macintosh way" if you expect success on that platform.
Certainly, it's a different way of working, and you'd have put some thought
into how to structure the project. From a cost standpoint, though, even if
you ignore the development advantages, releasing the source is a lot
cheaper than writing the documentation for a library API. And, perhaps
unlike the Windows platform, Linux developers would rather have source, anyway.
It's certainly a project design worth considering.
Bryn Paul Arnold Jones
Hash: SHA1
On Tue, 12 Jan 1999, Jacob Hawley wrote:
> Not an easy question to answer.
>
> Short Answer:
> Under DOS/Windows it is about 98% compatible.
>
> Long Answer:
> The PCI bus does not support ISA IRQ/DMA requests. In addition, the I/O ranges
> that are typically used for Sound Blaster (220h - Basic Audio, 680h - WaveTable,
> 200h for Joystick) are not supported in the PCI config space.
>
[...]
> We have found a couple of instances where the support
> does not work properly, these are primarily with VIA PCI chipsets.
>
Yes, but VIA chipsets seem to have problems with the ISA cards too ...
> 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.
For those platforms you have total control anyway, unlike the dos/windows
mess where you can talk directly to the hardware should you be so
inclined.
Basically you can (and IMHO should) use the hardware abstraction inherent
in the OS to wave goodbye to the need to support the legacy interfaces as
only the kernel can talk to the hardware.
When I ask the question "Is it SoundBlaster<whatever> compatable ?" (and I
expect most of the other people asking from a linux point of view mean
this too), I really mean "If I configure my kernel to talk to this card as
a SoundBlaster<whatever>, will it act as one ?". The answer for some
cards is "If you say this magic incantation at it first, then yes", but in
this case the answer seems to be "No".
Hmm, I just thought of something... Can the card be configured to act as
a SoundBlaster<whatever> compatable, _but_ with it's ports appearing at
0xXXXX (ie in the PCI range). Because we don't have problems with that
(though the SoundBlaster<whatever> driver may need tweaked), because of
our abstractions.
If that is the case (which would make sense from a legacy support point of
view as you then need to do less tweaking of the data "stream" in the
dos/windows driver), you would be able to have a basic audio driver out
the door and in the kernel in a week and then release more advanced
support when it's ready.
> 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".
>
Which is moot with hardware abstraction ;).
> Jake
>
Bryn
- --
PGP pubkeys from http://www.gytha.demon.co.uk/pubkey.asc.
Men often believe -- or pretend -- that the "Law" is something sacred, or at
least a science -- an unfounded assumption very convenient to governments.
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Comment: Silly comment here ...
Charset: noconv
iQA/AwUBNpy7jd94IUtvfSqaEQIJzQCgnH5FwKDxUHfbs5YXK16E3OslHdsAoKXz
OYAk2PqsdGcbjjkd415/f/Tr
=CZhg
-----END PGP SIGNATURE-----
Mike A. Harris
>> 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
Tygrys
> >- 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.
That's right. Sombody ought to tell Creative (?) Labs & 4Front about
it...
--
Greetz,
Tygrys [161-Tango Delta Echo-002] - at 27MHz
if I have a bad day, ;-)
("`-''-/").___..--''"`-._ TyGrYs *** ExPeCt No MeRcY! ***
`6_ 6 ) `-. ( ).`-._-. KSS Network Administrator
(_Y_.)' ._ ) `._ `. "-..' http://www.tygrys.eu.org/
_..`--'_..-_/ /--'_.'_,' ICQ:3297597 LU156-NIC 2:484/53@fidonet
(((' (((-((('' (((( Linux Forever!!! Member of JTZ
Ben Hutchings
> > 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 already has SoundBlaster emulation through OSS. Wine doesn't
need it, since Windows programs are expected to use the Windows
audio drivers.
--
Ben Hutchings, software engineer | web site to be reconstructed at some time
wom...@ferret.lmh.ox.ac.uk | Team *AMIGA* | Jay Miner Society - www.jms.org
Life is what happens to you while you're busy making other plans.
- John Lennon