Open-Source Creative X-Fi Support

[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:

1. 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).
2. 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.
3. 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.
4. 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.
5. 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? >:-)

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.

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.