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.
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: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: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: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.
Slashdot Mirror
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
there are Mac/PPC drivers in the tree already, and some of the PCI-based cards have been tested under Linux on the Alpha.
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.
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.