Slashdot Mirror
Linux Kernel 2.6.31 Released
diegocgteleline.es writes "The Linux kernel v2.6.31 has been released. Besides the desktop improvements and USB 3.0 support mentioned some days ago, there is an equivalent of FUSE for character devices that can be used for proxying OSS sound through ALSA, new tools for using hardware performance counters, readahead improvements, ATI Radeon KMS, Intel's Wireless Multicomm 3200 support, gcov support, a memory checker and a memory leak detector, a reimplementation of inotify and dnotify on top of a new filesystem notification infrastructure, btrfs improvements, support for IEEE 802.15.4, IPv4 over Firewire, new drivers and small improvements. The full list of changes can be found here."
I guess I really wasn't into linux until the last 3-4 years, but hasn't OS X done this since the start? And I think my XP machine at work tries to use Firewire as a network adapter.
What took so long, honest question.
Lots and lots of driver work. Over 70% of all of the 2.6.30 to 2.6.31 patch is under drivers/, and there's another 6%+ in firmware/ and sound/. That's not entirely unusual, but it does seem to be growing. My rough rule of thumb used to be "50% drivers, 50% everything else", but that's clearly not true any more (and hasn't been for a while - we've been 60%+ since after 2.6.27
I personally think this is a real pity. So much time is being spent on getting drivers implemented that new features and other kinds enhancements are being pushed back.
it is a good API and it IS the future of Linux desktop audio,
The future of linux audio it may be.. but good is questionable, no person using their linux machine for synths or midi would touch pulseaudio with a ten foot pole, jack is far superior with a lot less latency, but only applications designed for pro audio use tend to utilize it.
When this transitional period we are currently in is over, everyone will be much better off.
The latency incurred by pulse audio is horrendous, for youtube or movies that's fine, for gaming it's questionable, for music production it's nasty. These days completely removing pulseaudio and getting it all going again is quite an effort.
I can't imagine everyone being much better off, only those who want sound who don't care about the latency or from the music peoples perspective functionality.(jack can do a lot of things pulse can't do)
Support for what? A quick search of newegg tells me I can't buy a motherboard, add-on card, or peripheral that supports USB 3.0 today. What exactly was windows 7 going to support? An unreleased chipset?
From your own article:
Jeff Ravencraft of Intel said that he expects the final specification to be announced in San Jose, Calif., on November 17.
Wait, so I'm supposed to be upset that Microsoft didn't ship experimental drivers for an unratified standard in their new OS?
This scary graph [adobe.com] and related ideas tends to get mentioned in connection with this: this conflates libraries, sound servers, and drivers to some extent. One could draw a similar graph for windows, featuring programs using the Quicktime library, the WMP library, MME, DirectSound, WASAPI and various other APIs and libraries (and I haven't even gone into the changes to the audio driver model). WMP would have plenty of in arrows from applications using its libraries, and plenty of out arrows because it supports more than one API. And don't forget that there are still legacy applications which need to be the only app playing audio, just like on Linux.
Except Windows apps usually don't break just because there is a new flavor of the month in terms of audio. You can't argue that this is a good thing. The only reason it is OK in Linux is because most apps have source available. As usual, Windows makes the less pure choice (in terms of engineering), Linux does the right thing by abandoning the technology.
The fact that it is 2009 and there are still audio issues on Linux is telling, however.
OSS made it impossible to play more than one stream at once on a lot of hardware.
With a standard configuration, alsa does also, you have to load the dmix module in your config to act as a software mixer on cards that don't do hardware mixing (most on board bits).
This is where the userspace demons enter it all, most of them just started out as another layer that does software mixing, but every man and his dog came up with his own invention.
As for just using alsa, that's great if you don't mind not having certain functionality, some of the sound demons do add some nice features (jack is the only one I've found worth using though). It could be argued the driver layer shouldn't have to deal with some of that advanced functionality though, another reason why these demons were made.
OSS made it impossible to play more than one stream at once on a lot of hardware.
That was OSS 3. OSS 4 apparently allows you to do this on all hardware and is apparently much nicer than ALSA. It's also open source again. I read a good article about this situation a while ago but can't find it now.
Recently upgraded my motherboard to a new Gigabyte model which had on board HDMI and other audio for HDCP viewing. Needless to say, the standard ALSA packages for Ubuntu failed rather miserably to work. After several days of fighting with connectors, config files, reboots, re-installations and silent refusal to work, I only managed to get sound working by compiling ALSA from source. Of course, this now means that ALSA must be recompiled every time I upgrade the kernel. And I honestly can't hear any difference between the older OSS drivers and the ALSA ones.
Having to compile from source constitutes a major failure of any general purpose FOSS software.
OK, I'm appreciative of the fact that hardware manufacturers are a major problem in this area, as they have refused utterly to either release drivers or specs. However, the same concerns applied to monitors, network cards and graphics cards only a few years ago, yet these problems are largely behind us. There is one remaining important question here; Would these problems still exist if we had stuck with OSS? If the answer is no, then the move to ALSA has been a dreadful mistake.
May the Maths Be with you!
There were only need on Linux OSS because Linus refused to do audio mixing in the kernel. This means the resource sharing and hardware abstraction the kernel _should_ be doing was delegated to user-space.
eSATA seems like a much better solution.
I hope Apple starts putting eSATA/USB combined ports on their laptops soon.
Putting sound mixing in userspace has advantages and disadvantages. The first advantage is that it moves code out of the kernel, which is usually a good idea because bugs in the kernel can crash the entire system. The other advantage is that it can use the normal scheduler. This is less important now, but sound mixing used to be very processor-intensive compared with the total system load and if it's in the kernel it can't be easily preempted by userspace tasks. The big disadvantage is that, rather than copying the sound from userspace to kernelspace and then copying the mixed stream to the device, you need to copy it from userspace to userspace (if it's done via a pipe, you need to copy it from userspace to kernelspace then from kernelspace to userspace) and then copy the mixed stream from userspace to the kernel then from the kernel to the device. This adds latency and CPU load from all of the copying.
On a modern system, the amount of latency and CPU load added for userspace mixing is generally not large enough to matter. The other advantage of doing it in the kernel is largely cosmetic. It's the kernel's job to hide hardware differences from userspace software. If you implement mixing in the kernel, it is much easier to hide whether it's hardware or software mixing from the userspace software and remove the software mixer from the stack entirely when it's not needed. The new stuff in Linux removes this.
Note that the distinction between kernelspace and userspace isn't always clear-cut here. Some kernels run their device drivers, or parts of their device drivers, at a lower privilege level so, although they share the kernel's address space, they don't have access to all of it. On IA32, the obvious place for sound mixing is in ring-2, with the userspace code in ring 3, the driver in ring 1 and the kernel in ring 0. Unfortunately, this design would be completely non-portable so no one has bothered implementing it (except, possibly, OS/2).
I am TheRaven on Soylent News
What IS the PA latency, and the Jack latency? Jack seems idiotic; just use the sound card directly. Seriously, consider this: JACK -> ALSA, you can go directly to ALSA anyway (I haven't had a sound server for years). Do the mixing in your application and output it to ALSA. If real-time performance is an issue, don't run multiple apps at once. Record separate tracks versus a (monitored) metronome(!) when doing music, and then merge them with Audacity or GLAME.
"Professional" audio amateurs seem to all be n00bs, using their recording device (computer) for playback whereas real "professionals" use monitors, metronomes, visual cues, and master tracks. You monitor your metronome, monitor yourself, monitor the playback track, whatever; and record a separate track. Then later you digitally merge those together. QED. Whatever stupidity relies entirely on your computer being able to low-latency its way out of a paper bag for you to get any work done is a huge engineering error.
Support my political activism on Patreon.
The real fix would be to make PulseAudio use OpenAL optionally, so that cards that have accelerated mixing can be made to use it. I don't see the point though - not only are modern CPUs more than powerful enough to do it in userspace, they can't possibly have per-card defects while doing it.
Now that we do have PulseAudio it's best to trim as much fat and necrotic code from the kernel as possible. If the remaining realtime issues can be resolved, for which there is much experimental literature, it'll be perfect.
Sam ty sig.
It's not going to replace things like Jack (and OSS4 if that's available to you) but I don't think it's trying to.
It's trying to replace those weird LD_PRELOAD wrappers you have to use to make OSS-only apps speak to ALSA / PulseAudio. CUSE should be used to remove the need for LD_PRELOAD wrappers, making it more robust and simpler to use legacy OSS apps that can't use ALSA or PulseAudio directly. Regardless of what you think about replacing OSS, the current situation is pretty much pessimal: tricking applications into talking to the sound daemon, except sometimes it doesn't work.
If you're in the situation - right or wrong - of having a sound daemon, there should at least be a well-supported way of routing the sound from all apps into it. FUSE is slow partly because of more context switches and data copying. The context switches and (potentially) data copying are already required when a userspace daemon provides OSS emulation, so I can't see that CUSE will make this situation worse.
AFAICS, using CUSE to provide OSS emulation is pretty much unambiguously better for those already using a userspace sound server. For those who aren't, it doesn't affect them any more than the previous wrapper-based techniques did.
Yet they are curiously silent when commercial entities release derivative works under their own license.
Give me Classic Slashdot or give me death!
Exactly - I was having latency issues with some drum kit software I wrote, and found the problem to be pulse audio. It was adding a couple hundred milliseconds to the latency; this is completely unacceptable. After removing pulse audio from the system, everything was much better.
I like the features of pulse audio, especially per-application volume control, but it is not worth 200 ms latency to get it.
Cheers