Do you develop on GitHub? You can keep using GitHub but automatically sync your GitHub releases to SourceForge quickly and easily with this tool so your projects have a backup location, and get your project in front of SourceForge's nearly 20 million monthly users. It takes less than a minute. Get new users downloading your project releases today!
Posted
by
chrisd
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.
This discussion has been archived.
No new comments can be posted.
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.
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.
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 Anonymous Coward writes:
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.''
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.
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.
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:)
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.
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.
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.
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?
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).
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.
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.
Explanation? (Score:1, Interesting)
Re:good (Score:2, Interesting)
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.
Re:Linus Torvalds Merges Self with Tree!! (Score:2, Interesting)
Re:Vortex2 drivers (Score:2, Interesting)
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. ):
How cross-platform is ALSA? (Score:3, Interesting)
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)
ALSA of reminds me of the famous quote ``If you can persuade them with substance, dazzle 'em with bullshit.''
Re:What's going on with Linus? (Score:3, Interesting)
Re:What's going on with Linus? (Score:2, Interesting)
Great news for MIDI people (Score:2, Interesting)
Also, I really like the fact that it places all the sound devices under
x86-64! (Score:4, Interesting)
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)
Re:How cross-platform is ALSA? (Score:5, Interesting)
Two points: (Score:3, Interesting)
- 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.
Can we dump aRts and esd now? (Score:3, Interesting)
Re:great changes back to the old days (Score:4, Interesting)
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)
Re:Can we dump aRts and esd now? (Score:5, Interesting)
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:How cross-platform is ALSA? (Score:2, Interesting)