Open-Source Creative X-Fi Support

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

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

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

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

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

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

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

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

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

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