Open-Source Creative X-Fi Support

[phoronix]

Phoronix: Open-Source Creative X-Fi Support

Last Friday 4Front Technologies had released the binaries and source-code to OSS 4.0 Build 1013. This new build of the Open Sound System brings two major changes, which include the full source code now being available for the M-Audio Revolution and Delta sound card drivers, and a beta driver for the Sound Blast X-Fi series from Creative Labs. While earlier Sound Blaster generations have worked quite well with ALSA and OSS, the Creative X-Fi series is a black sheep under Linux. The X-Fi support that Creative Labs has provided to the Linux community has been abominable and support via ALSA (the Advanced Linux Sound Architecture) has yet to go anywhere while support for the complete X-Fi series via OSS is just starting to emerge. Interestingly though, Creative had provided the register documentation and other code to 4Front Technologies for this new "sbxfi" driver.

http://www.phoronix.com/vr.php?view=11797

[jackflap]

So, OSS is using copyrighted Creative Labs code in their open-source driver? I wonder where they got it from.

Seems likely that they somehow got their hands on the code of the binary beta driver that Creative released in September. I hope Creative doesn't ask for it back.

If Creative did hand over the code/specs to OSS, that's definitely a good thing, and a very useful way for companies to contribute to the open-source community, I will definitely support Creative for doing something like that.

I do wonder though, what issues may arise since it wasn't handed over by Creative as GPL.

Alex

Phoronix: Open-Source Creative X-Fi Support

Last Friday 4Front Technologies had released the binaries and source-code to OSS 4.0 Build 1013. This new build of the Open Sound System brings two major changes, which include the full source code now being available for the M-Audio Revolution and Delta sound card drivers, and a beta driver for the Sound Blast X-Fi series from Creative Labs. While earlier Sound Blaster generations have worked quite well with ALSA and OSS, the Creative X-Fi series is a black sheep under Linux. The X-Fi support that Creative Labs has provided to the Linux community has been abominable and support via ALSA (the Advanced Linux Sound Architecture) has yet to go anywhere while support for the complete X-Fi series via OSS is just starting to emerge. Interestingly though, Creative had provided the register documentation and other code to 4Front Technologies for this new "sbxfi" driver.

http://www.phoronix.com/vr.php?view=11797

[Michael]

Yes, they are using copyrighted code from Creative Labs in their OSS driver.

I'd expect 4Front got it legally. So far Creative has yet to respond.

[Rhettigan]

This makes me quite joyous. I hope that the recording support will continue to improve--it's the only thing keeping me from getting the XtremeGamer version with the $20 off coupon in the Bioshock box.

[DanL]

Awesome. Can Linux finally get rid of ALSA and go back to OSS? I know the developers would certainly be a lot happier since it's a lot easier to code for OSS than ALSA.

[Thetargos]

Does this mean Creative is readying a new generation release? Up until now I only knew the X-Fi like that "X-Fi", today I learnt that its actual name was Emu20K1 (makes sense as the Live! generation and its offspring was Emu10K1 [Live!] and Emu10K2 [Audigy]).

I certainly hope Creative will eventually actually release documentation (maybe inspired in so doing by AMD and Intel?) for Open Source developers (not only 4Front, or even if they are using 4Front as proxy) for their products. And not only that, but it would be awesome if they did indeed Open Sourced EAX, who knows? maybe even make it part of OpenAL (one can dream, can't one?) and also make available documentation for stuff like 96KHz and 24-bit sound on the Emu10K2 (Audigy) parts, as well as other "goodies" (I know Dolby Digital and DTS hardware decoding couldn't be disclosed, but if they could at least provide binary plugins for ALSA it would be swell [yes, another dream moment]), like maybe full capture capabilities, post-processing effects, etc...

*sigh* One can only wish, I know...


BTW, does anyone know if any of the other high end cards support hardware mixing in ALSA? That's actually very important to me, and the primary reason why I hold to this ancient Live! Value card of mine.

[Panix]

I might need a sound card for one of my computers. Whenever I pause video (for e.g., playing a DVD), I can hear buzzing whenever using my earphones.

Anyway, my question is, with this info, can I finally consider Sound Blaster X-Fi cards? Or should I stick with M-Audio or Delta cards? The latter are often expensive but I guess not all the cards are. I was looking at M-Audio Audiophile 2496, Revolution 5.1 (any reason to consider 7.1?) and any cheap Delta card (probably harder for me to find). Of course, the X-Fi cards are easiest to find but I read that they're only supported in Linux if using a 64-bit distro and by "support", who knows what that means.

[sobkas]

Yes, they are using copyrighted code from Creative Labs in their OSS driver.

I'd expect 4Front got it legally. So far Creative has yet to respond.
On the alsa mailing list I saw some interesting information:
http://thread.gmane.org/gmane.linux.alsa.devel/51306/focus=51341

To make it short, James Courtier-Dutton mention that he will receive datasheets "in the next week or so" from Creative and after that he might be able to shade some light on licensing of the current driver.

[Pseus]

Awesome. Can Linux finally get rid of ALSA and go back to OSS? I know the developers would certainly be a lot happier since it's a lot easier to code for OSS than ALSA.

ALSA can emulate OSS, what's the big deal?

[DanL]

ALSA can emulate OSS, what's the big deal?

http://4front-tech.com/hannublog/?p=5

[pzad]

Awesome. Can Linux finally get rid of ALSA and go back to OSS? I know the developers would certainly be a lot happier since it's a lot easier to code for OSS than ALSA.

OSS is dead on linux and it was killed by 4Front.

[mgc8]

http://4front-tech.com/hannublog/?p=5

As long as OSS is not GPL, it doesn't exist. This is stated in the comments section on that site, but it's also the truth. If OSS was under the same licensing terms like ALSA, then we could start a technically-oriented debate, and choose the one that is superior -- I don't think the kernel developers would really have a problem if that was the case.

Until that time, there really is no alternative to ALSA, for better or for worse.

That being said -- I always found the very idea of paying for drivers to be preposterous. Sure, if they actually offered some extraordinary improvement (like DTS or Dolby in hardware, that can't be had in free software); but just to be able to hear bleeps out of the hardware I actually paid for (!) should I shelve more money? that's insane.

[Uchikoma]

http://4front-tech.com/hannublog/?p=5

Now that, is an interesting read...also it appears that the OSS is now licensed:

- GPL2
- CDDL
- Commercial

The former option is the one of notice. So in that case...what's the problem, or am I missing something here?
Source: http://www.opensound.com/press/2007/oss-gpl-cddl.txt

[n3cr0]

OSS4 has been GPL2 for more then 8 months and still doesn't seem to be talked about that much.. I would very much enjoy the new version of OSS being a solid option in some Linux Distros

[Svartalf]

OSS is dead on linux and it was killed by 4Front.

Considering that the API's still much in use by everyone and that it's improved AND made GPLed, it might be time to re-evaluate things, much like it's come time to re-evaluate the sound frameworks in GNOME and KDE.

I do know that it's damned annoying to have to tapdance around all the issues from the various different (and utterly incompatible...) sound output frameworks. I'd already have one of the titles for LGP put to bed and off for final beta/gold mastering if it weren't for an obnoxious sound problem in the cutscenes with certain configurations for sound playback.

[Svartalf]

So in that case...what's the problem, or am I missing something here?

The problem is that many people making decisions for what is and isn't acceptable for API's into the kernel sound system and the driver layer for the same- they decided that they had a "better" idea and went with it when 4Front and others decided to squabble over OSS.

It might not be a bad idea to see what might be worth looking into here. If it brings many or all of the nicer promised features of ALSA without the convolution or the twitchy nature of the emulation, I'd be all for returning to that interface. All I care about is a uniform way to pump sound out the sound chip on a machine and one that won't be blocked by a single application. OSS didn't do that at the time. That's why ESD and ARTS came into being- to help deal with that "problem". But they didn't get traction because they weren't universal; they were only available to you if you had GNOME or KDE, respectively, on your system. So, now, you have got 3 differing, competing APIs. ALSA came along, promising to fix most of the mess. It didn't quite deliver on it's promise and it's a bit difficult to code to/for.

All I care about is having something that is decent to code for and just simply works without me being blocked to play back sound. So far, nobody's come up with a consistent answer as far as I can tell.

[Thetargos]

The problem is that many people making decisions for what is and isn't acceptable for API's into the kernel sound system and the driver layer for the same- they decided that they had a "better" idea and went with it when 4Front and others decided to squabble over OSS.

It might not be a bad idea to see what might be worth looking into here. If it brings many or all of the nicer promised features of ALSA without the convolution or the twitchy nature of the emulation, I'd be all for returning to that interface. All I care about is a uniform way to pump sound out the sound chip on a machine and one that won't be blocked by a single application. OSS didn't do that at the time. That's why ESD and ARTS came into being- to help deal with that "problem". But they didn't get traction because they weren't universal; they were only available to you if you had GNOME or KDE, respectively, on your system. So, now, you have got 3 differing, competing APIs. ALSA came along, promising to fix most of the mess. It didn't quite deliver on it's promise and it's a bit difficult to code to/for.

All I care about is having something that is decent to code for and just simply works without me being blocked to play back sound. So far, nobody's come up with a consistent answer as far as I can tell.
Ahem...

Don't forget that now you have PulseAudio too... so that makes for four different sound layers. Don't get me wrong, it IS great to have freedom of choice in systems like Linux, but just having too many choices (incompatible with one another, mind you) is not the way to have "freedom", especially for something that should "just work", and is expected to. In that way I see an edge in OSS over ALSA, in that it could grow to be "universal" to most Unix systems. Now that apparently it has been released under the GPL, that's even better. ALSA has some nice features as well, and offers more freedom in terms of configuration and what not (some times too much freedom, mind you). I don't know enough about each system to tell which is "better", all I know is that:


Redundant sound servers have to go away, which means no more ESD, no more aRTs... If PulseAudio can actually deliver what it seems to promise, then that'd be the one to use (IMO).
Wider and better hardware support. Which system offers the best hardware support and feature set? As far as I know, ALSA is the only one of both which actually supports "advanced" features in hardware such as Sound Blaster Audigy and Live! cards, like EAX (it has an EAX compiler and editor EMU10K1 based cards)... This doesn't mean that the driver or the library supports decoding of EAX in real time, only setting some effects for playback (like the EAX panel in Windows for the Live! and Audigy cards). I'm aware that the degree of support in most cases will depend on how much documentation the developers of each system had access to, in which case I see OSS with an advantage, as being a commercial product, they most likely had access to a wider variety of hardware than ALSA developers (I could be wrong, though) and support features like hardware mixing in hardware that actually has it, while ALSA does not support it. Again, I am no expert on both systems, so I can't say whic it is.
Criteria unification, both for driver and application development. If ALSA proves to be that superior to OSS, and could eventually outgrow Linux onto other Unix-like systems (becoming ASA-lib for all systems, and ALSA only for Linux drivers, and probably another acronym for the drivers in the rest of systems), it would be important to have unified criteria for the development of these apps, and how would they use the backend, currently OSS does provide that.
Better documentation. As stated in the blog entry, and I ignore if that is still the case, almost a year later, apparently the ALSA library is horrendously documented, not to mention that apparently (again based on that blog entry alone) it has a lot of redundant functions and routines. Proper documentation of the APIs (no matter which is chosen in the end) is imperative for good application development.
Ease of use, at the API level. It is a fact that easy to use APIs are more successful than those more cumbersome, no matter how "superior" they may be.


The last thing we need in Linux is "yet one thing to do something... That doesn't work (or not under 'certain' circumstances)" kind of approach to sound, especially not when other parts like graphics are moving to more standardized infrastructures. Thank God the XGL/AIGLX dichotomy was short lived (AIGLX being the clear "winner"). Just like X for graphics, a unified sound infrastructure is MUCH needed in Linux. No more ESD conflicts with x, y, z program or aRTs crashed when a, b, c sound stream reached it nonsense, Linux doesn't need many choices at the infrastructure level, but at the application level. Let the infrastructure be one (with flexibility to migrate, like it was the case with XF86 to Xorg), but keep it to one implemented at any given time.

My 2¢

[Silent Storm]

Even OSS is GPL, why should I get a key from them every 6 months and recomopile and re-install it? Yes, I can remove key system too but why should I bother when there's ALSA?

[Svartalf]

Ahem...
Don't forget that now you have PulseAudio too... so that makes for four different sound layers.


Heh... I've not at ALL forgotten that PulseAudio is around. It's because of that on my machines (works better than ESD and fixes a sound stuttering issue on my laptop with Ubuntu...) that I found out that we've a problem on at least one of the titles I've been put on to finalize for LGP. I'd have blessed what I've done for that title (can't say which one, sorry...) if I hadn't found out that the cutscenes don't play sound with that configuration. At all. Trying to sort out if it's something we've done or if the PulseAudio people need to be appraised of a problem right at the moment.



Don't get me wrong, it IS great to have freedom of choice in systems like Linux, but just having too many choices (incompatible with one another, mind you) is not the way to have "freedom", especially for something that should "just work", and is expected to.


I believe I did mention that I just want the stuff to be easy to work with AND just simply work on all targeted configurations. It's not much to ask for, now is it? >:-) :D


In that way I see an edge in OSS over ALSA, in that it could grow to be "universal" to most Unix systems. Now that apparently it has been released under the GPL, that's even better. ALSA has some nice features as well, and offers more freedom in terms of configuration and what not (some times too much freedom, mind you). I don't know enough about each system to tell which is "better", all I know is that:


OSS is simpler to work with. ALSA's more configurable and offers a broader range of ability- but this comes at a price. It's much, much more complicated to code for and there's no consistent API for it. Most of the people writing for ALSA are using wrappers such as SDL, etc. to actually USE it. I see that as a problem, really.


]Redundant sound servers have to go away, which means no more ESD, no more aRTs... If PulseAudio can actually deliver what it seems to promise, then that'd be the one to use (IMO).


Right now, PulseAudio's the most promising of the options available in people's hands. KDE may have something comparable- but if it's tied to KDE like ARTS is, we're going right back into the same fun and games before with ESD and ARTS.


Wider and better hardware support. Which system offers the best hardware support and feature set? As far as I know, ALSA is the only one of both which actually supports "advanced" features in hardware such as Sound Blaster Audigy and Live! cards, like EAX (it has an EAX compiler and editor EMU10K1 based cards)... This doesn't mean that the driver or the library supports decoding of EAX in real time, only setting some effects for playback (like the EAX panel in Windows for the Live! and Audigy cards). I'm aware that the degree of support in most cases will depend on how much documentation the developers of each system had access to, in which case I see OSS with an advantage, as being a commercial product, they most likely had access to a wider variety of hardware than ALSA developers (I could be wrong, though) and support features like hardware mixing in hardware that actually has it, while ALSA does not support it. Again, I am no expert on both systems, so I can't say whic it is.


It's six of one, half dozen of another. For device support, OSS has the edge. Until recently, though, they weren't a choice because they weren't truly GPLed. Now they are. This whole OSS/ALSA split occurred because someone at a certain Linux distribution vendor didn't like the lag, etc. and convinced people to "deprecate" the OSS interface. When ALSA started out, it was a promising thing and could have been where OSS is right now in platforms supported, etc. But, ALSA only resides in one place- Linux. I'm not sure what all to do here...but it's a damned mess and someone needs to step up to the plate, own up to it being a catastrophe and FIX it. People keep saying 4Front killed OSS on Linux- but I don't see that. ALSA's not getting where they promised people it'd be back when the split from OSS occurred. OSS is now GPLed and there's only a handful of reasons why someone would not consider it an option path for sound support. As it stands, it looks like Ubuntu's working on fixing it so you can configure the distribution up to use either OSS4 or ALSA for sound support, since they're planning on viewing those as device level interfaces and presenting something resembling a unified API so that anything needing sound can go through PulseAudio's layer.

I guess I need to dig into this mess further.


Criteria unification, both for driver and application development. If ALSA proves to be that superior to OSS, and could eventually outgrow Linux onto other Unix-like systems (becoming ASA-lib for all systems, and ALSA only for Linux drivers, and probably another acronym for the drivers in the rest of systems), it would be important to have unified criteria for the development of these apps, and how would they use the backend, currently OSS does provide that.


Considering that ALSA has had as long as it has had to get in position (Almost 10 years...), develop solid driver support, etc. and is no better off than it is and is rather tied to Linux right at the moment, I doubt that it'll get any further than our OS platform. I don't know if "advanced" is what we need. What we need is the ability to stream multiple sound sources to a mixer in hardware or software to a SINGLE sound card. A sound "bus" to play stuff out the speakers with. We really don't have that right at the moment. ALSA promised that and fell short. OSS didn't really do that at the time of the split, but since I've not looked at it since the split happened, I can't say what it can/can't do.


Better documentation. As stated in the blog entry, and I ignore if that is still the case, almost a year later, apparently the ALSA library is horrendously documented, not to mention that apparently (again based on that blog entry alone) it has a lot of redundant functions and routines. Proper documentation of the APIs (no matter which is chosen in the end) is imperative for good application development.


Heh... It's my understanding that it's not any better, really, now as it was then. I could be wrong though. :D


Ease of use, at the API level. It is a fact that easy to use APIs are more successful than those more cumbersome, no matter how "superior" they may be.


Heh... ALSA's not fun to directly use from my last recollections of trying to do it directly.

[DanL]

OSS4 has vmix as the answer to PulseAudio, which works great. I do believe it is time for the Linux community to abandon ALSA and work with OSS. The developers (dev and hannu on the 4front forum) are awesome. They have written a clean, portable, well-documented API that is great for both developers and users.

It is much easier to support users trying to get their sound working through OSS than ALSA. The problem is that there aren't enough people experienced with OSS to support users. We need more people to join the (counter)revolution, so install OSS4, because the latest release has X-fi support and open Envy24HT/M-Audio code.

[pzad]

OSS4 has vmix as the answer to PulseAudio, which works great. I do believe it is time for the Linux community to abandon ALSA and work with OSS. The developers (dev and hannu on the 4front forum) are awesome. They have written a clean, portable, well-documented API that is great for both developers and users.

It is much easier to support users trying to get their sound working through OSS than ALSA. The problem is that there aren't enough people experienced with OSS to support users. We need more people to join the (counter)revolution, so install OSS4, because the latest release has X-fi support and open Envy24HT/M-Audio code.

I think, it is time for you to wake up from your OSS dream. Future of sound in linux is ALSA.

[Thetargos]

Maybe I'm alone on this one, but it would be excellent if somehow both projects could "merge" (not in a literal sense, though). ALSA offers some very advanced functions directly tied to the underlying hardware that don't seem to be present in OSS (I ignore if such detailed control over the hardware is possible with OSS or not, with any particular supported "card"), this adds a bit more granularity to the whole Sound system in Linux. OSS on the other hand, offers a clearer/cleaner documentation of the API, is easier to implement (as there is no such broad control over the hardware, or not directly exposed through the API), and has broader OS support.

Now if somehow the advantages of each could generate the One True Sound System it would be awesome, and even though highly unlikely, I kind of see how at least ALSA could evolve. Generally speaking, and from what I have been able to make out of this whole deal, ALSA is such a "monster" to code for first and foremost due to the number of "undocumented" features and the sheer number of different functions (i.e, a complete mess). I don't think that the flexibility at the bare-metal level ALSA offers is necessarily a bad thing, I do think, however, that it should at least offer two levels to the API: Driver level and userspace level, kind of being the userspace level an abstraction layer on top of the drivers, and the library a "wrapper" to ensure proper communication. That way (and keep in mind I'm talking "blind" here, so I may simply be talking rubbish), application developers could use a very compact and "simple" API, while there would also be a more advanced API (or subset of the main API) for more direct hardware manipulation. I'm sure that's somewhat what it is today, and I'm also sure that OSS should work in such a way to an extent as well. My point is that ALSA could simplify the API, while still retain its flexibility. This, though requires that the library middleware between the low-level API and userspace applications will communicate effectively with any ALSA device regardless of driver idiosyncracies, for which it may have to even compensate.

At any rate, ALSA is still a young project, but it's taken its time to get to a more usable state. One thing is clear, though... Simplification of the Sound System in Linux is imperative, and has to occur FAST.

[Regenwald]

well, pulseaudio _will_ replace esd. esd is too old, too crappy, too buggy and pa is very promising. fedora 8 has it already installed by default (but it seems to make lot of problems, look at their bugzilla...), ubuntu is going to adopt it, so i think that it is just a question of time until pa is in "vanilla-gnome"...
btw: oss is even available under the bsd-licence (check http://developer.opensound.com/), but i think that alsa is the way to go. the linux-kernel gets more and more rid of oss-drivers, more alsa-based drivers are coming in...forget oss ;) perhaps in *bsd, opensolaris, but in linux..i don't think so.

[Svartalf]

I think, it is time for you to wake up from your OSS dream. Future of sound in linux is ALSA.

Have you ever written software for it? Or for sound playback in general on Linux? If not, please spare us the commentary- ALSA's a damned pain to write code for. It offers some great features- but if you can't USE the damned things, it's of little use. OSS is simple to code for, but a LOT of people keep going on and on about ALSA being the "future" and it got edged out of the OS, even though it's "universal" on all the other *nix type platforms for sound support (There's a hint that maybe we've gone down a blind alley...)

I don't care about the "future"- I want the stuff to just work. It DOESN'T right now. I'm not able to ship a game title right at the moment BECAUSE it doesn't freakin' work across ALL setups. ALSA doesn't bring it, and neither does OSS right at the moment- for whatever reasons they have for that on each respective API for base sound playback.

If the "future" doesn't offer this, we need to seriously reevaluate all of it. We need to come up with something that's easier to use in it's basic form, that's well documented for that edge as well as any advanced edges, and is what one can reasonably get access to on everything on Linux. Something analogous to what DirectSound used to be on XP systems. Screw "elegant". Screw "choice". This is baseline infrastructure stuff. DRI-like stuff. Gallium-like stuff. ONE interface to drive it. On top of it you should be able to layer everything else on it. You want Jack? Great, run it. You want PulseAudio? Great, run that too. If ALSA can't give me that, it's not the "future" any more than OSS was back at the time of the split from it.

And...people, keep in mind, I've been using and coding for Linux since 1994 here. I still never did quite get why we did this split in the first place, nor did I get why it's taken ALSA 10 years to get to the place they're currently at that doesn't work any better in it's own ways than OSS did back then. This is getting QUITE old, actually. If cleaning up the situation with ALSA will do this, great. If making some more advanced features in OSS will do that, then great as well. It just needs to be fixed.

[DanL]

I think, it is time for you to wake up from your OSS dream. Future of sound in linux is ALSA.
You may say I 'm a dreamer, but I'm not the only one. I hope some day you will join ua, and the world will be as one.

[Thetargos]

Svartalf: I couldn't have worded it better, and I really, really hope you can around the issues you are experimenting, we need more games!!!

DanL:

ROFL @ the Lennon pun, good one!