Follow Slashdot stories on Twitter


Forgot your password?
Linux Software

Linus Merges ALSA Into 2.5.4 302

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

Comments Filter:
  • Explanation? (Score:1, Interesting)

    by Mr.Phil ( 128836 ) on Wednesday February 13, 2002 @09:25PM (#3004465)
    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:good (Score:2, Interesting)

    by psamuels ( 64397 ) on Wednesday February 13, 2002 @09:43PM (#3004560) Homepage
    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.

  • by Anonymous Coward on Wednesday February 13, 2002 @09:48PM (#3004589)
    Wasn't that a STNG episode?
  • Re:Vortex2 drivers (Score:2, Interesting)

    by psamuels ( 64397 ) on Wednesday February 13, 2002 @09:50PM (#3004604) Homepage
    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. ):

  • by Snowfox ( 34467 ) <(ten.xofwons) (ta) (xofwons)> 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?

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

    by Anonymous Coward on Wednesday February 13, 2002 @09:57PM (#3004634)
    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.''

  • by Dwonis ( 52652 ) on Wednesday February 13, 2002 @10:02PM (#3004655)
    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.
  • by aeil ( 183600 ) on Wednesday February 13, 2002 @10:02PM (#3004660) Homepage
    Yeah but the pre-emt stuff has been around for a while and has had many happy users. ie: tested -- fairly stable. probably related to a don't fsck up and add a new VM at the end of a development cycle screw up.
  • by dmouritsendk ( 321667 ) on Wednesday February 13, 2002 @10:13PM (#3004701)
    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 :)
  • 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.

  • Re:BIG MISTAKE! (Score:3, Interesting)

    by paulbd ( 118132 ) on Wednesday February 13, 2002 @10:41PM (#3004813) Homepage
    You're either a troll or you don't know anything about something you write with an authoritative tone about. The design of ALSA with respect to SMP systems, spin locking and interlocking access is probably better than almost any existing system in the kernel. As for deferrment of interrupt handling, thats entirely a function of individual "lowlevel" card drivers, and its possible that there are better ways for certain drivers to handle their hardware's interrupt. However, audio hardware is real-time in that it continues to run whether the CPU services it promptly or not. This requires a rather different kind of design than the one used for, say, disk drives. finally, the proof is in the pudding. many of us have been using ALSA for several years, and it has worked better on both UP and SMP systems than the old OSS API, and without any bizarre kernel issues.
  • by paulbd ( 118132 ) on Wednesday February 13, 2002 @10:53PM (#3004860) Homepage
    there are Mac/PPC drivers in the tree already, and some of the PCI-based cards have been tested under Linux on the Alpha.
  • 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.

  • 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?
  • 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. :)

  • 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.
  • by Error27 ( 100234 ) <.error27. .at.> on Thursday February 14, 2002 @02:24AM (#3005532) Homepage Journal
    >> The Linux sound situation is really retarded.


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

  • by Ewasx ( 207402 ) on Thursday February 14, 2002 @08:37AM (#3006273)
    I've been able to use the alsa drivers with a GUS soundcard on an old alpha without any problems or modifications. So I think they're pretty portable.

"An organization dries up if you don't challenge it with growth." -- Mark Shepherd, former President and CEO of Texas Instruments