Announcement

Collapse
No announcement yet.

Open-Source Creative X-Fi Support

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Thetargos
    replied
    Originally posted by Svartalf View Post
    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?

    Leave a comment:


  • Svartalf
    replied
    Originally posted by Uchikoma View Post
    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.

    Leave a comment:


  • Svartalf
    replied
    Originally posted by pzad View Post
    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.

    Leave a comment:


  • n3cr0
    replied
    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

    Leave a comment:


  • Uchikoma
    replied
    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
    Last edited by Uchikoma; 02-07-2008, 01:37 PM.

    Leave a comment:


  • mgc8
    replied
    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.

    Leave a comment:


  • pzad
    replied
    Originally posted by DanL View Post
    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.

    Leave a comment:


  • DanL
    replied
    Originally posted by Pseus View Post
    ALSA can emulate OSS, what's the big deal?
    http://4front-tech.com/hannublog/?p=5

    Leave a comment:


  • Pseus
    replied
    Originally posted by DanL View Post
    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?

    Leave a comment:


  • sobkas
    replied
    Originally posted by Michael View Post
    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....06/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.

    Leave a comment:

Working...
X