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.
Linus Torvalds Merges Self with Tree!!
by
Pedro+Picasso
·
· Score: 4, Funny
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
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 =)
Please say they fixed the emu10k1 mixer & MIDI
by
Cerlyn
·
· Score: 3, Informative
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?
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
Well, there's Ardour... the CVS build is currently very broken because of a move to use jack, but once that's complete...
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.
How cross-platform is ALSA?
by
Snowfox
·
· Score: 3, Interesting
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:How cross-platform is ALSA?
by
paulbd
·
· Score: 5, Interesting
there are Mac/PPC drivers in the tree already, and some of the PCI-based cards have been tested under Linux on the Alpha.
Re:What's going on with Linus?
by
Dwonis
·
· Score: 3, Interesting
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.
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.
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.
-- "How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
Re:What's going on with Linus?
by
Prop
·
· Score: 3, Funny
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.
You mean, like, a....VM ????
..... grin.....
Re:BIG MISTAKE!
by
paulbd
·
· Score: 3, Interesting
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.
Re:ALSA does not impress me
by
paulbd
·
· Score: 3, Informative
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.
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.
-- A deep unwavering belief is a sure sign you're missing something...
Can we dump aRts and esd now?
by
be-fan
·
· Score: 3, Interesting
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?
-- A deep unwavering belief is a sure sign you're missing something...
Re:Can we dump aRts and esd now?
by
Error27
·
· Score: 5, Interesting
>> 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.
Re:What's going on with Linus - he's retiring ...
by
konmaskisin
·
· Score: 5, Funny
... 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....
Re:great changes back to the old days
by
LunaticLeo
·
· Score: 4, Interesting
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.:)
-- --
I am not a fanatic, I am a true believer.
Re:ALSA in any distro default kernels?
by
mlinksva
·
· Score: 3, Informative
Didn't think of it before posting, but distrowatch 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.
There is no Linus.
by
EvilAlien
·
· Score: 5, Funny
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.
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.
Re:good
by
Anonymous Coward
·
· Score: 3, Funny
"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)
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
Re:BIG MISTAKE!
by
paulbd
·
· Score: 3, Informative
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.
Slashdot Mirror
Try this FAQ
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.
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."
--
(sourceCode == freeSpeech)
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 =)
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!)
Hope this helps..
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
Well, there's Ardour... the CVS build is currently very broken because of a move to use jack, but once that's complete...
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.
Has this changed? If not, is it really wanted in the stock Linux kernel yet? Have any used ALSA with non-PC hardware yet?
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.
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.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
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.
You mean, like, a ....VM ????
..... grin .....
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.
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.
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.
A deep unwavering belief is a sure sign you're missing something...
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?
A deep unwavering belief is a sure sign you're missing something...
... 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 :-)
... 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.
... 10 years will pass and then some hacker will come along and ....
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
Linux will have reached maturity and will reign the world during its coming golden era.
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. :)
-- I am not a fanatic, I am a true believer.
Didn't think of it before posting, but distrowatch 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.
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.
perl -e 'print $i=pack(c5, (41*2), sqrt(7056), (unpack(c,H)-2), oct(115), 10)'
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.
"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)
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
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.