Posted by
chrisd
on from the it's-water-helen-water dept.
davster writes "I was just checking out the Linux 2.5changeset 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.
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...
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.
To anyone who is wondering: this is a Big Deal
by
matusa
·
· Score: 5, Informative
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 (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 =)
Re:Explanation?
by
psamuels
·
· Score: 5, Informative
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..
-- "How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
ALSA = Advanced Linux Sound Architecture
by
Stonehead
·
· Score: 5, Informative
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. 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?
by
Snowfox
·
· Score: 5, Informative
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:What's going on with Linus?
by
RedWizzard
·
· Score: 4, Informative
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.
JACK + ALSA = future PCM subsystem for Linux!
by
Adnans
·
· Score: 5, Informative
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.
Shameless plug:-) AlsaPlayer 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
-- "In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
Slashdot Mirror
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
Love many, trust a few, do harm to none.
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 (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 =)
Hope this helps..
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
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. 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
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.
ALSA = lowlevel soundcard drivers
:-) ..and it makes Linux a worthy competitor to OS X's CoreAudio.
:-) AlsaPlayer 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).
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
More on this at the JACK website
Shameless plug
-adnans
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds