Linus Merges ALSA Into 2.5.4

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.

Re:Explanation?

[Sarcazmo]

Try this FAQ [alsa-project.org]

ASLA?

[PhotoGuy]

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

Re:what is alsa?

[topside420]

For more information on ALSA, visit http://www.alsa-project.org/ [alsa-project.org] as posted within the article body.

To anyone who is wondering: this is a Big Deal

[matusa]

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

[Cerlyn]

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

Re:Explanation?

[psamuels]

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

ALSA = Advanced Linux Sound Architecture

[Stonehead]

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 :)

Re:What's going on with Linus?

[Snowfox]

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.

Re:ASLA?

[paulbd]

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:What's going on with Linus?

[RedWizzard]

Him trying BitKeeper is huge considering his previous professed hatred of source control systems.

Also, it's big news because of all the problems that were plaguing 2.4 for so long, many of which were attributable to him not accepting important patches from people. So BitKeeper was news because it's a step towards resolving those problems.

Professed where? He has said that he doesn't like CVS and that he doesn't think any source control system will help much but he's never said he hates them generally. He has been promising Larry McVoy he'd give BitKeeper a try for more than two years. If he sticks with BK then it'll be news, but at the moment he hasn't changed his mind about source control. And if you think this will make any difference to the issue with dropped patches you're sadly mistaken. That's a seperate problem that has nothing to do with source control.

Re:Explanation?

[SuzanneA]

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.

Re:ALSA = Advanced Linux Sound Architecture

[psamuels]

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)

Re:ASLA?

[paulbd]

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:ALSA does not impress me

[paulbd]

Your anonymous coward status doesn't impress me. ALSA was designed by essentially 2 people for the audio side and 2-3 for the MIDI side. What committee? Either you were asleep or you were never a part of the discussions on alsa-devel that led to the current design. Any complexity it presents is a result of a desire to be able to handle any and all audio interfaces, which a simpler structure (and we tried many) could not do. No, ALSA was not designed with the ordinary end-user in mind. ALSA is a set of device drivers. It is part of the kernel, which provides mechanism, not policy, for user space. The stuff that will be designed for users mostly doesn't exist yet because too many audio developers have continued to write code around the OSS API. they can't be blamed entirely - the ALSA API was incredibly unstable for some time. yes, its poorly documented. no its not extremely buggy. hardware support is wider than OSS and in some specific areas, deeper.

Re:ALSA in any distro default kernels?

[d3xt3r]

Yep in SuSE at least since 7.0. It's their default sound system.

Re:Two points:

[psamuels]

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.

Re:ALSA in any distro default kernels?

[mlinksva]

Didn't think of it before posting, but distrowatch [distrowatch.com] indicates whether and what version each of a few dozen distros ship with (not just ALSA, dozens of packages). Yep, as two followups have indicated, SuSE and Mandrake have included ALSA for awhile. That's a good thing. Don't know why someone thought I was trolling, it was an honest (if lazy) question.

JACK + ALSA = future PCM subsystem for Linux!

[Adnans]

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

Re:BIG MISTAKE!

[paulbd]

the design of ALSA divides it into 3 layers. alsa-lib lives in user space, and provides a friendlier API for audio+MIDI than POSIX' open/read/write/close/ioctl calls. within the kernel there is the "midlevel" layer which is generic across all support hardware, and then the "lowlevel" layer which contains drivers specific to certain hardware. The lowlevel drivers are the responsibility of specific authors and can be changed, fixed, altered and otherwise evolved quite independently of the midlevel ALSA code. Thats why the specific operation of a given lowlevel driver is not the point - if it defers interrupt handling incorrectly, or not at all, then just that low level driver is broken, not ALSA in general. if you believe that the mid-level code contains the potential for a priority inversion, then you should explain why in some detail. if you have examples of low-level drivers that have similar issues, it would be wise to point them out. however, my impression is that you don't know how ALSA has been designed, nor its record of successful operation to date. when priority inversion is a possibility, its generally not that hard to induce. i have never seen any report of this on alsa-devel or linux-kernel since ALSA begain development.