Originally posted by DanL
View Post
Announcement
Collapse
No announcement yet.
Open-Source Creative X-Fi Support
Collapse
X
-
Originally posted by DanL View Post
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.
Comment
-
Originally posted by DanL View Post
- 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.txtLast edited by Uchikoma; 07 February 2008, 01:37 PM.
Comment
-
Originally posted by pzad View PostOSS is dead on linux and it was killed by 4Front.
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.
Comment
-
Originally posted by Uchikoma View PostSo in that case...what's the problem, or am I missing something here?
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.
Comment
-
Originally posted by Svartalf View PostThe 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.
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?
Comment
-
Originally posted by Thetargos View PostAhem...
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.
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.
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.Last edited by Svartalf; 08 February 2008, 04:30 PM.
Comment
-
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.
Comment
Comment