Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Linus Merges ALSA Into 2.5.4 302

Posted by chrisd from the it's-water-helen-water dept.
davster writes "I was just checking out the Linux 2.5 changeset and noticed that Linus has just merged ALSA into his tree. Its about time." CD: Looks like Jaroslav Kysela did the merge work, but Linus obviously allowed it to happen. I'm a happy Alsa user so this looks like a good thing.
This discussion has been archived. No new comments can be posted.

Linus Merges ALSA Into 2.5.4 More

Linus Merges ALSA Into 2.5.4

Comments Filter:

  • Explanation? (Score:1, Interesting)

    by Mr.Phil ( 128836 )
    Can someone explain to me what this means? I've never had trouble with the sound modules that came with the kernel before. Every time I've installed Linux since the 2.0.5 days, my sound cards (always Sound Blasters) have been supported just fine.

    • Re:Explanation? (Score:3, Informative)

      by Sarcazmo ( 555312 )
      Try this FAQ [alsa-project.org]

    • Re:Explanation? (Score:5, Informative)

      by psamuels ( 64397 ) on Wednesday February 13, 2002 @09:37PM (#3004537) Homepage
      Can someone explain to me what this means? I've never had trouble with the sound modules that came with the kernel before.
      • range of hardware - ALSA supports more cards than the existing OSS-based stuff
      • features - the first "A" in ALSA is "Advanced". The original OSS API is rather limited as to what it allows an application to do. Doesn't affect me much, because I have a motherboard OPL3SA chip with its crappy FM synthesizer (so MIDI sounds really lousy) - but if you have newer hardware with its leet DSP effects including 3D simulation, etc, the old drivers will never allow an app (read: game) to take full advantage of it. ALSA may not be as advanced as DirectX - I have no idea - but it's a sight better than OSS.
      • new infrastructure - ALSA is a sort of "clean slate" and gets rid of many of the annoying limitations of the current architecture, like only letting one app use the card at a time (some current drivers have this limitation even though the hardware supports multiple input channels - sure you can get around this with a sound daemon such as aRts or esd, but still).

      Hope this helps..

      • Re:Explanation? (Score:2, Informative)

        by SuzanneA ( 526699 )
        Doesn't affect me much, because I have a motherboard OPL3SA chip with its crappy FM synthesizer (so MIDI sounds really lousy)

        As a perfect example of why Alsa is powerful, take a look at RX/Saturno [reduz.com.ar]

        Its a Yamaha DX7 emulator that installs itself as a virtual ASLA midi port, that any Alsa MIDI player/app can use.

        Basically, the ALSA architecture can, in theory, let you work around your OPL midi limitation. You can install 'virtual' drivers that use wavetable, or whatever, synthesis to provide better MIDI playback.

    • > my sound cards *(always Sound Blasters)* have been
      > supported just fine.

      You more or less answered your question.

    • Re:Explanation? (Score:1, Interesting)

      by Anonymous Coward
      Imagine some third or fourth year CS student without much real world experience, but pumped up on hormones and Jolt cola. Now instead of writing maybe 100 lines of Pascal or C code to solve a problem, that they feel "elite" and decide to do something different. So instead of the previously mentioned simple code, they build this incredible Dungeons and Dragons complex framework with all sorts of illogical extensions, doo-dads, gee-gaws, and gizmos. That is ALSA in a nutshell. Just imagine the worst aspects of Debian applied to a complete sub-system.

      ALSA of reminds me of the famous quote ``If you can persuade them with substance, dazzle 'em with bullshit.''

  • Sweeet! (Score:2, Funny)

    by laptop006 ( 37721 )
    Thou I'm still waiting for Pro Tools support...

  • finally sound config in linux will no longer be a
    Big Thing(tm)

    however i wonder why this is big news because there are so many important things which are getting merged. i guess sound has a more generic audience:)

    Vikram

    • Re:good (Score:2, Interesting)

      by psamuels ( 64397 )
      however i wonder why this is big news because there are so many important things which are getting merged.

      It is a big deal - ALSA has been "on the horizon" with many happy users ever since the late 2.1 days. Jaroslav didn't feel it was ready for prime time by 2.2 and missed the boat with 2.4, so I'm glad ALSA finally made it.

      Now if Linus will just accept Keith Owens's new Makefile structure, I'll be a happy man. (Same goes, to a lesser extent, for Eric Raymond's new configuration infrastructure.) He said a year ago it would happen in the 2.5.1 - 2.5.2 timeframe, now it looks like he may be backpedaling ... oh well.

      • Wait. He said it wasn't ready for 2.2, yet still missed 2.4?????
        • Wait. He said it wasn't ready for 2.2, yet still missed 2.4?????

          Yup. Late 2.3 was really weird. Actually it was a lot like other kernel cycles, come to think of it. Linus did the usual feature-freeze-no-wait-let's-put-in-LVM-ok-now-fea ture-freeze thing, and eventually replaced the whole memory manager in the 2.3.99 series somewhere (later replacing that in 2.4.10, as is now common knowledge) ... but really everyone was in a holding pattern figuring Linus would release the real 2.4 Any Day Now, for quite some time. It was an easy boat to miss. Reiserfs missed it, actually - Hans Reiser was up in arms about that - but then Linus let it in in 2.4.1 or 2.4.2 since it was pretty much self-contained.

      • Same goes, to a lesser extent, for Eric Raymond's new configuration infrastructure

        I want the config adventure game!!!!!!

      • Re:good (Score:3, Funny)

        by Anonymous Coward
        "Eric Raymond"? Who he? Ah, I think you must mean... ESR!

        (Chorus:) I am EEE ESS ORR, elite hack-ORR, hear me ROAR!
        1.
        I am of the hacker elite, can't you see?
        fetchmail, blindfolds in nethack, er... (hum-hum diddle dee)
        Bow down on your knees, don't you diss me!

        (chorus)
        2.
        I am an author, I "wrote" New Hacker's Dictionary
        Well, in fact I done stole it from MIT
        I didn't get in there, so I figured they owed me!

        (chorus)
        3.
        I am founder and leader of OSI
        Now my Open Source show is really on the road!
        Free Software? Hah! Show me dat code!

        (chorus)
        4.
        I am ESR Skywalker, elite Jedi Knight
        I'm packing mah gun and I'm ready to fight
        You diss me and I'll send you to eternal night!

        (chorus)
        5.
        I am wealthy board member, VA Something-or-other
        Got plenty dollar bills, at least on paper
        What's that? Dot.com crash? Oh fuck! See you later!

        (chorus x 2)
  • I'm not complaining/trolling (actually, I'm happy with the news), but it's interesting to notice what Linus is up to recently:

    - he is considering to use BitKeeper
    - he accepted the preemptive kernel in the kernel
    - he did something else I don't recall now (will search slashdot after this post :)
    - he accepted alsa on the kernel

    Maybe he is finally realizing that Linux is not only "his toy" anymore...
    • The Illuminati got to him. Through their cooperation with the Grays, and the secret rich elite, they have pressured Linus into compliance. They hate MS as much as we do, after all MS is a threat to their power.
    • ...or perhaps he's recognizing that these other projects are maturing and can now be consided "worthy" of kernel level inclusion.

    • Re:What's going on with Linus? (Score:5, Informative)

      by Snowfox ( 34467 ) <snowfox@[ ]wfox.net ['sno' in gap]> on Wednesday February 13, 2002 @09:49PM (#3004600) Homepage
      I'm not complaining/trolling (actually, I'm happy with the news), but it's interesting to notice what Linus is up to recently:

      - he is considering to use BitKeeper
      - he accepted the preemptive kernel in the kernel
      - he did something else I don't recall now (will search slashdot after this post :)
      - he accepted alsa on the kernel

      Maybe he is finally realizing that Linux is not only "his toy" anymore...

      I think you're missing something.

      Kernel versions with an even number in the second position are meant to be stable. Nothing risky goes in these.

      Kernel versions with an odd number in the second position are development versions. This is where risky and innovative new technology can be introduced and experimented with.

      Linus only recently opened the 2.5 kernel series. He's been maintaining 2.4. I believe what you're attributing to ownership is his being aware of the fact that a broken "stable" kernel could do terrible damage, and nifty new sound bits and experimental reworking of the task scheduler aren't worth taking that risk.

      • Linus only recently opened the 2.5 kernel series. He's been maintaining 2.4. I believe what you're attributing to ownership is his being aware of the fact that a broken "stable" kernel could do terrible damage, and nifty new sound bits and experimental reworking of the task scheduler aren't worth taking that risk.

        So... how do you explain him ripping out the memory manager in the middle of a stable series and replacing it with entirely new, undocumented code?

        I think you're missing something...
        • He ripped out the existing 2.4 memory management code to replace it with an updated version of the 2.2 memory management code, not something completely new.

          As for documented, from what I've read, neither VM system is very well documented.
      • I think you're missing something.

        True. I actually didn't express well my opinion in the first post (I also missed this response to the slashdot submission system or to mozilla 0.9.8 forms :).

        Kernel versions with an odd number in the second position are development versions

        I know that. What I was surprised with was the quick acceptance of such patches, in particular the preemptive one. Judging by the following interview [linuxdevices.com], I think that even Robert Love was skeptical about it:

        Love: Linus said at ALS this year he was interested in the preempt-kernel patch. That doesn't mean anything to me until we are in, though, but it is a good sign.

        There is opposition. There are various issues that need to be dealt with. I believe it is a sane move for 2.5. The patch has seen a lot of testing and we have a lot of users.
        I do not want to predict whether it will be merged for 2.5. Time will tell.
    • Linus hasn't had a real development (odd-minor-numbered) kernel for over a year. Now, he's accepting everything he wanted to before, but didn't because it could break too many things.
    • Maybe he is finally realizing that Linux is not only "his toy" anymore...

      no matter what happens to the kernel, it will always be his toy ;-)

      but maybe people will fork of and start making there own toys, who knows

    • Re:What's going on with Linus - he's retiring ... (Score:5, Funny)

      by konmaskisin ( 213498 ) on Wednesday February 13, 2002 @11:23PM (#3004989) Journal
      ... once he cleans house for a while and modularizes all the interfaces nicely and a cool python based gui/curses/none config system is ready (i.e. when linux will have reached 2.5.99 ... 2 years from now) he will begin to ascend the mountain leaving his creation behind. After all there will no longer be a big pile of source called the "linux kernel" maintained by Linus at that point. There will be a refined and perfected architecture into which pieces of code, drivers modules can be inserted in ways that require zero or no changes to other modules. It will be as easy to write drivers and kernel modules as it is to write apache modules and CGI scripts. Kernel modules in java and python will be all the rage ... written by grade school kids and retired grannies :-)

      The much ballyhooed and silly myth of Linux being unmaintainable by one person will be proven moot once and for all. At that point the kernel will be "maintained" by a vast decentralized and motly unorganized army of engineers, and hackers because Linus will have designed it so. One or two people per module
      who may never even talk to another mdoule driver owners ... that's the secret that's coming. Their will be an "official" Linux on sourceforge say. Any code or modules to be included will only compile and work in the official kernel if it plugs into the source control and build system nicely (which will require documentation strings and a clean code style) all enforced by machine. The core code will only change every 6 months to a year ... or maybe never. After all BSDi kernel hasn't changed too much nor QNX ... when something is good and done it stays the same for a while.

      Linux will have reached maturity and will reign the world during its coming golden era. ... 10 years will pass and then some hacker will come along and ....

      • There is no Linus. (Score:5, Funny)

        by EvilAlien ( 133134 ) on Thursday February 14, 2002 @01:28AM (#3005401) Journal
        Linus is a myth. There is no Linus, never was. He is a fictional person created to explain the spontaneous evolution of Linux from code snippets by pure chance. Linus is a crutch used by those who require a neat and tidy explanation for this phenomenom.

        Furthermore, there is no meaning to Linux. It just is. Its complex, its dynamic, its really difficult to explain and predict in detail. The VM fiasco was in fact a stronger species of VM being introduced into the environment by accident. We believe that it may have been smuggled in by a BSD user, and having no strong natural enemies it was vulnerable to, simply pushed out the weaker indigenous VM species. Again, this is all chance.

        When will we wake up and stop attempting to explain things by invoking some higher power, creator, kernel maintainer, what-have-you? Wake up, darwin wasn't talking about odd monkey-creatures in Madagascar, he was talking about Linux.

  • I still have one of the old Aureal Vortex2 cards, which has (in part) a binary-only driver module. Could this be modified to work inside the ALSA framework in 2.6?
    • nope, unless the alsa dudes get the specs to program the vortex2 chip.

      I wish them good luck, because my team (the one from the partly-binaries one at sourceforge) never had a glimpse on them.

      All we did was based on hocus-pocus and reverse engineering :-P

    • Re:Vortex2 drivers (Score:2, Interesting)

      by psamuels ( 64397 )
      I still have one of the old Aureal Vortex2 cards, which has (in part) a binary-only driver module. Could this be modified to work inside the ALSA framework in 2.6?

      Depends - what do you mean by "in part"? I'm assuming the binary-only part is combined with a shim layer which is compiled from source?

      If that's the case, it may be possible to rework the shim layer to support the ALSA API, but you might have some trouble getting hackers to do it for you. Many of them are more interested in supporting open hardware, after all. On the other hand, several people worked on winmodem drivers long before anyone provided much documentation for those chips, so perhaps someone will port it for you.

      Alternatively, try your hand at porting it yourself, or pay someone to hack on it....

      Or you could ask the company to develop ALSA drivers ... oops, I forgot, there is no company. ):

  • ASLA? (Score:4, Informative)

    by PhotoGuy ( 189467 ) on Wednesday February 13, 2002 @09:30PM (#3004495) Homepage
    It would be nice to have a three or four word description of what ALSA was in the article. (Advanced Linux Sound Architecture, for those who don't know.)

    It would not only save people a bit of time, but avoid everyone who doesn't know, having to click through to the page, increasing chances of an unnecessary slashdot effect...

    -me
    • oooo thanks for clearing that up - I thought it was going to be an automated thing to answer those A/S/L ? questions... but I couldn't figure out what that extra A was for.

    • Re:ASLA? (Score:5, Informative)

      by paulbd ( 118132 ) on Wednesday February 13, 2002 @10:01PM (#3004652) Homepage
      ALSA is a complete redesign of the sound subsystem for Linux. It addresses a number of areas that were irretrievably broken in the old "OSS" design:
      • application access was always via direct access to /dev/* nodes, requiring all format conversion and other "fancy" code to reside in the kernel
      • no possible generic support for non-interleaved cards
      • no uniform API for mmap-based access
      • no support for advanced h/w features without highly hw-specific code
      When using ALSA, although it remains theoretically possible to use open/read/write/ioctl/close(2) and access /dev/snd/pcm*, all applications will almost certainly use alsa-lib, which provides a flexible, powerful way to access and control audio and MIDI hardware. format conversion, (de|re)interleaving code and many other commonly required operations live in this user space library, leaving the device drivers to simply present a suitably abstract version of the hardware they support. In addition, ALSA addresses many areas of SMP comptability that were unreliable or just plain broken in OSS. Fixing these in OSS was a per-card affair, with some better than others. Under ALSA, the design of the entire system is SMP friendly.

      • Re:ASLA? (Score:1)

        by BJH ( 11355 )
        application access was always via direct access to /dev/* nodes, requiring all format conversion and other "fancy" code to reside in the kernel

        I'd like to see more info on this - what exactly would require format conversion to be in the kernel? Linus and Alan explicitly rejected such an approach for the v4l code, requiring that all format conversion be done in userspace. I find it hard to believe that the kernel sound code did all conversion between 8/16bit, big-endian/little-endian, etc.

        • Re:ASLA? (Score:2, Informative)

          by paulbd ( 118132 )
          let me put that another way. the OSS API required that the data delivered to the interface match the way the interface was configured. this results in every app that needs to write floating point data to an interface requiring 16bit samples to handle it themselves. dumb. however, when the OSS API is used with a card for which there is no existing configuration description possible with OSS (the RME Hammerfall is the canonical example), then all the format conversion between the format used in user space (to match the OSS description of the configuration) and the actual hardware setup has to be in the kernel, since nothing interposes between the write(2) call and the driver itself. what was also in the kernel (for example) was the code to drive the OSS "soft synth". there was really nowhere else to put this because of the design of the OSS "sequencer" (which in both ALSA and OSS is really a router and scheduler rather than a "sequencer" in the conventional sense). this is because access to the OSS sequencer is via a /dev/ node, and thus all code related to its operation has to be in kernel space. with the low latency patch and SCHED_{FIFO|RR} scheduling there is no reason to put a soft synth of any type in the kernel. i have been trying to encourage the ALSA sequencer coder(s) to move most of it into user space, for similar reasons. sorry for the misleading suggestion that all format conversion code was in the kernel before.

          • Re:ASLA? (Score:1)

            by BJH ( 11355 )
            Thanks for that, it explained the problem nicely.

  • Arts? (Score:1)

    by svara ( 467664 )
    There were some problems with alsa and arts with yamaha ds-xg soundcards... a lot of fixes went into 2.4.x for arts and oss with those cards...

    So, does that mean that arts for yamaha ds-xg just got broken?
    • Had the same problem, you need to set the sample rate to 48KHz IIRC... then the ds-xg sounds nice. Btw, the oss ds-xg drivers don't have the same quality or functionality as alsa..
      • Btw, the oss ds-xg drivers don't have the same quality or functionality as alsa..

        Last time I tried Alsa from CVS (just a couple weeks back), that was definately not true. Alsa didn't support hardware midi support, which the OSS drivers support. In addition, the OSS drivers support both rear and front speakers. The OSS emulation in the Alsa drivers only supported one set on the Yamaha ds-xg cards.

        Dinivin

  • Linus Torvalds Merges Self with Tree!! (Score:4, Funny)

    by Pedro Picasso ( 1727 ) on Wednesday February 13, 2002 @09:32PM (#3004507) Homepage Journal
    CYBERSPACE, USA - In a freak accident at Transmeta World Headquarters this afternoon, famed programmer Linus Torvalds -- creator of the Linux operating system kernel -- accidentally merged himself into the kernel's dev tree. When reached for comment, Torvalds seemed only able to respond with "Power overwhelming."

    Alan Cox, another prominent GNU/Linux programmer said he thought the merging -- though accidental -- was a good thing. "Now that [Linus]is actually in the kernel he can take advantage of Linux's multitasking and actually handle the work-load that he has. This is a really good thing for the community." Added Cox, "It's also pretty [freaking] weird."

  • To anyone who is wondering: this is a Big Deal (Score:5, Informative)

    by matusa ( 132837 ) <chisel@nOspAm.gmail.com> on Wednesday February 13, 2002 @09:34PM (#3004516) Homepage
    Alsa has been hoping for kernel inclusion for _quite_ a long time. If you search mailing list archives, this issue has been around for a while, and has been a serious issue since the 2.0 days IIRC.

    Some history, Alsa kindof grew out of the enhanced Gravis ultrasound drivers (not to say that you'll find any code lingering.. it just came out of that project).

    That said, this will bump up linux sound a quantum leap.

    The major thing that caused ALSA to not be included was stability--their API would change drastically and suddenly all the time (which may be a good thing, though it was done VERY suddenly and often without notice). That aside that has stabilized as they approach a 1.0 release.

    Note that there are oss compatability functions, and support for tons of soundcards, so don't think that thinks will stop working.

    As a matter of fact, you can expect this to really push things forward (yes I'm repeating myself, but I can't stress this enough). Many good sound apps now already require ALSA. if you check out their website [alsa-project.org] (linked in the main story), amongst other info you can find their supported card matrix.

    I tip my hat to the ALSA team, for their great work and perseverance. thanks a million!! We can all look forward to better sound (more features, lower latency, more flexible API, everything you want) now =)

  • Please say they fixed the emu10k1 mixer & MIDI (Score:3, Informative)

    by Cerlyn ( 202990 ) on Wednesday February 13, 2002 @09:36PM (#3004529)

    The last time I tried ALSA (0.9.0beta9) with a Sound Blaster Live!, I was confounded with the way they presented the mixer setup. It provided me with dozens of individual effect and audio sends, "mutes" that actually turned things on, confusingly named controls for laypeople, etc. While their wavetable MIDI worked for the most part, I have songs that suddenly mute one or more channels, with notes always cut short (no sustains).

    Fortunately, the wonderful thing about the Linux kernel is that one can often find alternative (OSS_Free, etc.) drivers. I'm not putting ALSA down; I like how it is progressing, and it has the wavetable support that the OSS Free-style driver presently lacks. Hopefully ALSA's inclusion into 2.5 will help coax more people to find bugs, add cards, and fix problems.

    (Before anyone flames me, I did file bug reports to ALSA. Many projects seems to be drowning in them; if you want to get into open source development and cannot code, perhaps you could help verify reported bugs!)

    • Yes, I was also stymied by the way ALSA presents the SBLive! mixer. Having a second-hand card without any documentation doesn't help me at all. Can anyone explain why the headphone right/left mute buttons are labeled 'Headphone LFE1' (for the Right channel) and 'Headphone Center 1' (for Left)? Why can't I record from my LiveDrive! Line in? What crack-smoker coded this shit?

      Don't know about other versions, but 0.9.0beta9 & beta10 are both like this.
  • I had problems with the latest KDE's ARTs and ALSA in the past. As soon as YMF724 became available in the kernel itself, the problems seemed to dissapear. Will there be a choice for people like me between the ALSA implementation and the old one? Or have all the problems been fixed in ALSA? I always liked alsa as a strong and stable driver system in the past, so this has to be good news.
  • WOOO! I can have a soundblaster without damned modules in embedded systems again! OSS was a grand project but it sucked royally because it forced module use.

    Many times I had to reverse patch the kernel to get soundblaster back in without OSS. Now with ALSA I can compile the sound driver back into the kernel and fling off the last bit of module code that was worthless for embedded systems.
    • I've *never* gone modular with the soundblaster drivers, ever. this includes a sb16isa with SCSI2, a sb16pci, and a sblive!. maybe your just to stupid to read documentation?
    • What on Earth are you talking about? Until recently (as in 2.2.17 or so) I always compiled the sb driver in.

    • Re:great changes back to the old days (Score:4, Interesting)

      by LunaticLeo ( 3949 ) on Thursday February 14, 2002 @12:00AM (#3005124) Homepage
      OSS was a grand project but it sucked royally because it forced module use.

      Then you will LOVE the 2.5+ kernels. Soon the kernel will be module only. They are creating a new kernel boot format that will pack all the modules with the kernel. There will be a few more tricks to keep modules close in memory (for platforms which distinguish short jumps from long ones). Wallah! no more bifurcated init code (one code for compiled in and another for modules).

      Good luck for all the module haters. :)

  • ALSA = Advanced Linux Sound Architecture (Score:5, Informative)

    by Stonehead ( 87327 ) on Wednesday February 13, 2002 @09:48PM (#3004595)
    ALSA has been merged into the development Linux kernel, version 2.5.5-pre1, not 2.5.4 as mentioned in the title. Bad Slashdot editors.. :(
    Jaroslav Kysela, a Czech developer paid by SuSE, has worked for years to create and lead the ALSA project [alsa-project.org]. It's GPL - its code has always been intended to go into the mainstream kernel and replace the OSS code. Linus has just done so.
    Okay, what does it do: ALSA is just a set of utilities, general code and drivers for soundcards. After 4Front Technologies went commercial with OSS some years ago, Linux did not have supported GPLed soundcard drivers anymore. The commercial OSS-drivers are up-to-date, but those in the Linux kernel are old. A lot of obscure soundcards are currently only supported under Linux by either adding the commercial binary OSS modules, or adding the ALSA modules to your kernel. For example, my Aztech 2320 and Mediaforte cards that wouldn't even work with the legacy Win95 drivers (newer aren't to be found anywhere), nor with the old OSS, but they work very cleanly with ALSA since two years. Believe me, the ALSA codebase rocks. It has been stable for a long time and is good enough to add to your 2.4 kernel yourself. Visit the web site, it's just as easy as compiling any other module. And uh, before you all flood the ALSA mailinglists, start alsamixer first before testing, because all channels start muted as default :)
    • ALSA has been merged into the development Linux kernel, version 2.5.5-pre1, not 2.5.4 as mentioned in the title. Bad Slashdot editors.. :(

      The mistake was probably due to the BK changelog, which quotes Jaroslav's email message:

      Integrate ALSA into v2.5.4

      Jaroslav

      (@*#&$^(*& llllaaaammmmeeeennnneeeessssssss ffffiiiilllltttteeeerrrr)

  • 0.5? (Score:2, Funny)

    by spt ( 557979 )

    Version 0.5?

    Whatever happened to the "always wait until version 3" rule of stable computing?
    • Then call it version 5.0 and be happy.

      Numbers are meaningless when everyone has their own numbering schemes.
    • So, version 3 equals stable? Let's see here... remember Windows 3.0? How about DOS 3.0? Heck, the Linux kernel isn't 3.0.

  • How cross-platform is ALSA? (Score:3, Interesting)

    by Snowfox ( 34467 ) <snowfox@[ ]wfox.net ['sno' in gap]> on Wednesday February 13, 2002 @09:52PM (#3004611) Homepage
    It was my understanding that the ALSA group was only interested in supporting PC hardware.

    Has this changed? If not, is it really wanted in the stock Linux kernel yet? Have any used ALSA with non-PC hardware yet?

  • Si, no, plans? Anyone know? I hope they don't all wait for 2.6.
  • This and the peemptiple patch makes you think linus is lining up towards multimedia.

    Good to know.

  • In my experince ALSA provides great MIDI support, and it seems like they support MIDI on alot more cards than the OSS(example: I first learned about ALSA when i couldnt get OSS to work with the midiport on a Yamaha waveforce).

    Also, I really like the fact that it places all the sound devices under /dev/snd/ , structure is good :)
  • Many of the newer (and better) sound cards are not supported in 0.5. Midiman cards for instance are only supported in the "beta" 0.9 version.

    Otherwise, this is definitely good news.

  • x86-64! (Score:4, Interesting)

    by psamuels ( 64397 ) on Wednesday February 13, 2002 @10:22PM (#3004743) Homepage

    Did anyone notice that Linus also integrated x86-64? Now AMD's vapor 64-bit offering is on an equal footing with Intel's vapid 64-bit offering.

    (OT: According to a local SGI sales rep, a lot of the big Unix vendors got burned by the whole Itanium fiasco. I said I was curious a couple years ago why the vendors were all so quick to drop their own chips in favor of ia64, and he said "because we were stupid".)

    I'm not sure I agree with creating a whole new arch for x86-64 rather than making it conditional stuff within i386. Yes, I realise, this was already done by sparc64, mips64 and ppc64, but that doesn't make it right. I think I would prefer the approach used by arm and superh - having sub-architectures within the main arch framework. Oh well, I guess that's why I'm not Linus.

  • CS4624 Support? (Score:1, Troll)

    by ewhac ( 5844 )

    So, um... Is Crystal SoundFusion CS4624 support working yet?

    I have a Hercules Gamesurround Fortissimo II (replaced my AWE64). It wasn't clear if the OSS modules included with kernel 2.2.19 supported it, so I decided to give ALSA a try. I downloaded and installed ALSA 0.5 some time ago. While the modules detected my card and configured themselves just fine, I got no sound out of the speakers. (Yes, I used alsamixer to turn up the volume on the appropriate channels.)

    Someone on the alsa-user mailing list suggested it might have something to do with the "power management" on the newer chip, and to try ALSA 0.9.something (alpha-ware), which has code to handle it. So I did. It compiled, installed, detected my card, and configured itself just fine. alsamixer opens and lets me fool with sliders without trouble. Even the OSS compatibility modules come up fine. But I still can't hear anything.

    I haven't touched it since then, as I've been consumed by other distractions. Clearly I'm doing something wrong. But I'm at a complete loss as to what it might be.

    Schwab

    • NICE card. I used the 2.4.x CS4624 drivers, and they worked ok - you should probably give them a try yourself.
    • Sounds like you've not unmuted the audio channels.

      Muteing is separate from the volume, in alsamixer I think the key is M to mute/unmute.

      Do excuse if you already tried that, but you haven't mentioned it, and it is one of the gotcha's with ALSA (Anyone know why they mute by default?)

  • Two points: (Score:3, Interesting)

    by be-fan ( 61476 ) on Wednesday February 13, 2002 @11:11PM (#3004945)
    1) Wow! Is Linux 2.6 going to kick ass or what! We've got in the stock kernel:
    - New block-io layer
    - ALSA
    - Preemption + lock breaking
    - New driver model with more transparency
    - VM reworking
    - New page cache (RSN, currently in -dj tree)
    Plus patches that easy to add
    - O(1) scheduler
    - XFS
    Is Linux going to be a great desktop (oh, server too...) kernel or what!

    2) Is Linus insane? With all those changes, we'll be lucky to see 2.6 sometime this decade! And the end result won't likely be the most stable thing ever.

    Still, I like living on the edge, so I'll probably end up switching to 2.5 at the tail end of the cycle.

    • Re:Two points: (Score:2, Informative)

      by psamuels ( 64397 )
      We've got in the stock kernel:
      [deletia]

      You forgot new input device layer. If we get the matching new console layer, multi-head will be pretty much built in. (Yes, I know XFree86 supports multiple displays - I'm talking about multiple sets of keyboard+mouse+video running independently of each other. SGI has sold dual-console workstations for a long time - why can't I do this with Linux, y'know?)

      Oh yeah, there's also USB 2.0, but that's more of a driver update than a whole new thing.

      ...And x86-64 (also in 2.5.5pre1), so we're ready for the Hammer when it comes out.

      ...And better filesystem threading. The unstoppable Al Viro just added fine-grained locking to a couple more VFS calls in 2.5.5pre1. I guess it isn't really news, more of a work in progress; he has been improving VFS scalability since mid-to-late 2.3.

      • ...And x86-64 (also in 2.5.5pre1), so we're ready for the Hammer when it comes out.
        >>>>
        That's what I love about Linux ;) And it took Microsoft how long after the i386 came out to actually release a 32-bit OS?
    • If I were Linus, I'd do a feature freeze right now, get all the bugs out over the next few months, and release Linux 2.6 this summer.

  • Can we dump aRts and esd now? (Score:3, Interesting)

    by be-fan ( 61476 ) on Wednesday February 13, 2002 @11:20PM (#3004977)
    The Linux sound situation is really retarded. There are tons of APIs and sound servers and none of them work! Sound-servers in general are dumb ideas that went away when soundcards with hardware mixers were invented. Don't get me wrong, a server is necessary to allow media apps to communicate with each other, but something like aRts (which doesn't take advantage of sound card special features) ties all the nifty media framework stuff to a stupid sound multiplexer. Yikes. For 99% of applications, sound isn't a difficult things. There is no reason for all these sound servers to be in existance. God dammit, how many programming interfaces do you need to occasionally play "Ding!" when mail arrives?
    • Two things:
      Network capability
      and
      Hardware limitations.
      Typically, hardware cards don't do more thon 3 or four sound channels at once. Sure, more than we can usually listen two, but still, a lot more limited than these programs.
      Besides, though alsa supported it first, I can have multiple applications directly use dsp without software daemons, though it is an sb live..
      Alsa is far more advanced and we finally get to see it coming mainstream (first it was going to be in 2.1, then put off to 2.3, and finally, and 2.5 we see it. Of course, the OSS is less and less important as more of the sound modules lie outside the OSS every release... (EMU10k1, VIA audio, etc...)

    • Re:Can we dump aRts and esd now? (Score:5, Interesting)

      by Error27 ( 100234 ) <error27 AT gmail DOT com> on Thursday February 14, 2002 @02:24AM (#3005532) Homepage Journal
      >> The Linux sound situation is really retarded.

      Correct.

      There was an interesting discussion on the alsa-devel list in January about "Alsa and the future of sound on Linux." Paul Davis the author of jackit.sf.net wrote some pretty convincing emails that a call back system is better than the popular Linux way with read/write like a file.

      Jackit is designed for high end audio but it's really similar to Apple's CoreAudio. The problem is that most Linux developers don't want to mess around with callbacks and multi-threaded programming. And quite frankly most sound applications don't require such a high level of quality.

      A good thing to do would be to change aRts to write to jack. That way you could use jack for the high end and aRts for basic mp3s etc.

      Unfortunately jack is not finished yet.

  • So how has support for multiple cards changed? I don't know anything about Linux's sound system, but I ask because I know it is making headway in high end 3D work, and it could start to be a driving force in high end audio work (and various other sound applications) if the groundwork was in place.

  • Drivers? (Score:3, Interesting)

    by iabervon ( 1971 ) on Thursday February 14, 2002 @02:07AM (#3005500) Homepage Journal
    The ALSA interface code is unquestionably much better; one of the main reasons for ALSA was to get a saner interface. Many of the drivers are better, and there are drivers for some cards that OSS didn't support at all. However, there are also some cards with more stable OSS drivers. Are there any plans to merge the driver set, keeping the better of the overlapping drivers, and spliting the driver choice from the interface choice? The reports I've heard say that the Yamaha OSS drivers are more stable, so it would be nice to stick with them without losing the up-to-date interface.

  • JACK + ALSA = future PCM subsystem for Linux! (Score:5, Informative)

    by Adnans ( 2862 ) on Thursday February 14, 2002 @06:52AM (#3006006) Homepage Journal
    ALSA = lowlevel soundcard drivers
    JACK = highlevel audio (PCM) API

    So JACK is using ALSA to output audio. The nice thing about JACK is that it's the first serious attempt in the Linux (Unix) world to get a professional audio API in the hands of developers. SGI's dmSDK was promising but that project seem to have stalled, i.e. no open development going on (no CVS). JACK also replaces arts and esd when it comes to multiplexing audio output. The only problem is that developers may find they have to redesign their whole audio application in order to fit inside the JACK (callback based) framework.

    A typical Linux/Unix audio application opens a special file and starts writing the audio data to it. The application will block on the write() (or read() when recording). This works fine for simple things like playing an mp3 or doing some window manager sound. It gets hairy when you try to sync multiple audio applications and achieve low latency at the same time. With jack this is as easy as pie, because the applications are driven by the JACK callback. So when it is time for the soundcard to get its next buffer JACK simple calls the process() function of all the connected audio applications. Every application has the chance to insert its own piece of audio data (or inspect what's already there), all app will always write the exact same amount of samples per callback, which keeps them in perfect sync. You can also do cool things like create your own ports and wire JACK aware apps together. In short, it rocks :-) ..and it makes Linux a worthy competitor to OS X's CoreAudio.

    More on this at the JACK website [sf.net]

    Shameless plug :-) AlsaPlayer [alsaplayer.org] was the first released JACK app, mainly because of its BeOS heritage (the internals work exactly like the ancient BeOS audio_server, which was callback based).

    -adnans

    • With jack this is as easy as pie, because the applications are driven by the JACK callback. So when it is
      time for the soundcard to get its next buffer JACK simple calls the process() function of all the connected audio
      applications.


      Ok, I can see how this is good and all, but I think you're forgetting about geek culture here--on of the main draws of this API is if you don't know it...[you fill in the rest, I don't feel that I can bear the responsibility]
  • Sorry for a "What about me" post.

    I can't help wonder how this will affect cross platform unix development of multimedia apps. New Linux stuff will do doubt start being targetted to ALSA only (and quite right too, some things *need* a unified architecture). I did a google for ALSA FreeBSD but nothing looked very hopeful (I mean the L is an L for a reason!).

    I'd be unhappy if Id engines stopped being FreeBSD friendly.

    I guess I'll have to wait and see.
  • The overwhelming majority of sound card users seems to have one or two applications in mind and don't see others. Basically, we want to hear music coming out of speakers or headphones. We'd like to have the encoding for multichannel audio (e.g., theatre sound) but "IP" problems tend to make that goal unattainable. Other than that, though, 16bit 2-channel 44.1khz audio seems to be acceptable. And we should be able to take it for granted. It should NOT take months of study and effort to get that far.

    Now, there are other types of users who need a very different feature set from the same system.

    Musicians want to use the capability of the computer for multitrack recording. We'd like to be able to use cards with hardware mixers, cards that record 24bit audio, cards that use standard timecode protocols required for video and all other professional recording. We'd like to be able to do every step of a production in a fully digital format, never using an ADC/DAC device.

    Some of us would also like to be able to use the computer as a musical instrument. The potential is there for the home computer to outperform and vastly outfeature the expensive samplers, analog modelling synths, and multitrack digital recorders whose pricetags shut out most musicians in the working class.

    A feature like "64 simultaneous voices" sounds like overkill, until you're trying to record a piano wavetable on a romantic piece with a sustain pedal. At that point, 64 voices is like CGA compared to SVGA.

Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Close