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."
Give it up already, Richard.
Enhancements should come as a part of the OS, not the kernel. The main function of a kernel is to get along with all the hardware devices on the system. Drivers should be given a high priority.
Face your daemons!
amen. OSS, alsa, pulseaudio, for christsake just give me sound that works without having a million handler processes.
OSS was okay.
Good people go to bed earlier.
What evidence have you got that suggests driver development means other development is pushed back? Do you think the EXT4 developers take time off to write device drivers?
Lots of driver development means Linux has lots of driver developers. That probably suggests that hardware manufacturers actually try to get their stuff supported.
From the changelog
*The new firewire driver stack is no longer considered experimental, and distributors are encouraged to migrate from the ieee1394 stack to the firewire stack
*Added IP networking to the new FireWire driver stack
It does add up. It's just added to the new stack, old stack has it already.
The fact that, with a modern Linux distro, I can plug in pretty much any hardware at least a year old and have it just work no questions asked is a pretty damn spiffy feature.
So just use ALSA!
The situation on Linux is that there used to be OSS, and now there is ALSA. ALSA works fine, for pretty much everybody. There are a few legacy apps which use OSS because no one is updating them, and obviously, it would be nice if they would play nice. Pulseaudio is a bit strange, but nothing requires it's use, and IMHO there is no real reason for it to be used unless you want to do somewhat strange things (that you generally can't do on any other type of OS). Don't use pulseaudio if you don't want to; if your distro forces it on you, use a sane one.
This scary graph 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.
Here is why I can't be bothered to learn enough about the driver layer to give examples: "UAA is intended to be a complete replacement for developing WDM Audio Drivers; however, in some cases it may be necessary for an otherwise UAA-compliant audio device to expose capabilities that cannot be done through UAA. Windows will continue to fully support audio drivers that use the PortCls and AVStream drivers.
Audio technology has evolved, lots. Having backward compatibility requires that things get slightly complex. Everybody is doing this. I think Linux is doing it rather well, although certain distros make some odd choices.
OSS made it impossible to play more than one stream at once on a lot of hardware.
# cat
Damn, my RAM is full of llamas.
What bothers me here is that I read "Oh, change this, do that turn this knob and sound will work for you." Then it works until there's a new kernel update (I use Ubuntu) and it breaks again. Or it just stops working after too many applications use it.
Then you read how fabulous PulseAudio is and how wonderful it is, but it just plain does not work. By working, it should work every time, all the the time without knob turning. It's embarrassing that in this area, Windows 95 is superior to Linux in almost every respect.
All this effort is put into chrome polishing the kernel for faster SMP with 64 CPU systems and the dang box can't even play music without having some sort of brain failure.
Before we all moved on to worrying about PulseAudio it was traditional for us to complain about legacy apps using OSS, the difficulties associated with wrapping them, the nastiness associated with OSS emulation being implemented in the kernel, etc. Those apps won't have gone away.
Previous attempts to emulate OSS using ALSA have included the aoss tool, which I believe did some mildly ungodly tricks to intercept calls that would usually go to the OSS APIs. It didn't always work, for me, as it depends on what the (often weird and proprietary) app is doing to access the OSS API in the first place. PulseAudio has to provide a tool to help you redirect legacy OSS apps to talk to PulseAudio instead. It's all Made Of Ick.
CUSE (character devices in userspace) allows a userspace program to provide a character device node in /dev and implement it using custom code, rather than relying on an in-kernel driver. When apps open the device node they'll *really* be talking to the userspace daemon implementing the device emulation, rather than to an in-kernel driver (though, of course, the kernel will be involved in relaying the communications through the device interface). This is very similar to what FUSE does for filesystems. The neat thing here is that weird tricks to catch OSS accesses by applications are not needed - the OSS device can simply be "faked" by the real sound daemon. Because it's implemented at device level, it doesn't matter what nasty hacks the OSS application is doing to access the soundcard - you'll *always* be able to grab its sound output from the fake device and do the right thing. No more running legacy apps with an OSS-related wrapper - and no more having the wrapper fail to work!
The end result should be that sound Just Works, even for awkward proprietary apps. CUSE will not automagically fix this on it's own, though - we need to wait for the sound daemons like PulseAudio to catch up and implement the emulation. This might also allow OSS emulation to be removed from the kernel, which AFAIK also supports some variant of OSS-on-ALSA.
PA is for desktop audio. For pro audio production you'll run JACK and have PA output its audio to JACK instead of directly to ALSA. That way your pro audio apps will get their super low latency and all of the apps that can get away with 50ms latency will play through PA to JACK. You get the best of both worlds.
My other account has a 3-digit UID.
Improved acronym support!
Numbers higher than the last version!
greater infusion processor link array warp drive systems!
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?
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.
it is a good API and it IS the future of Linux desktop audio,
It may be a good API, but it's not a good implementation. But yeah, I can agree that glitchy, high latency audio is the future of Linux desktop audio.
Give me Classic Slashdot or give me death!
I'd argue that drivers should be modular and have no business being directly in the kernel in the first place - but that's just me.
I don't anyone ever argued that drivers should not be modular, in fact that's why there's kernel modules. I'm guessing you're talking about one of the two general flamewars:
1) Monolithic kernel or microkernel
2) Stable ABI for drivers
The first is about making the kernel into a big message-passing daemon, which it turns out has a performance penalty and ultimately doesn't have big enough benefits because a kernel panic and a major subsystem hang/crash both are ugly and if the hardware is left in a borked state it might not really help.
The other is a stable ABI, which has been suggested about 234,533,458 times to date. My only real comment to that is that seeing how crappy many Windows drivers are, do you honestly want them making blobs for a 1% operating system which will get about as much priority, support and bugfixes? Drivers based on specs or donated source almost always suck less.
Live today, because you never know what tomorrow brings
"Pretty much every distribution has standardized on Pulseaudio" is the very definition of regress. What you said was getting better and better? I installed Debian unstable on my laptop, with KDE desktop, and it also installed and enabled this trainwreck called "PulseAudio", which serves as only purpose to disable the audio of an already working system. Sound has worked for me in Linux since forever, never had any problems with it until PulseAudio came around.
During the early days I had been using a sound card with hardware mixing. Back then even Windows wasn't coping well with several streams and a card supporting only one, so what OSS offered back then was good enough for me, and on par with other operating systems. Then came ALSA, which offered dmix and dsnoop to do it software. Now, dsnoop has never worked for me, but I don't know any other operating system that supports such a feature so I guess I don't have much ground to complain.
Then PulseAudio came around, and that is the first time when I had any problem with sound on Linux. Sound started to be skippy, jumpy, choppy, and not working in some applications. Why would anyone think that PulseAudio would be a good idea? Now, don't get me wrong, I like PulseAudio, I even use it for some tasks. Namely playing music from my laptop on the soundcard of my desktop. But thanks to the brilliant idea that PulseAudio should be used everywhere I couldn't really do that anymore, because I had to eradicate PulseAudio to have sound again, so I couldn't use it for *my* needs. Fuck me.
Disclaimer: I'm not sure I'm chronologically correct above, the sound might have been in a better state in Windows than in Linux during OSS times, I just mean that I was already used to being able to play only *one* sound at a time when I first came to use Linux, so it seemed pretty normal thing to me.
For tape-based systems, or for situations where a chain of components are expecting a DV stream to be arriving on schedule, you really can't beat firewire. And, for that reason, nearly any PC being used for DV editing will have firewire onboard. Nicer motherboards have it standard, PCI/PCIe expansion cards are cheap if yours doesn't.
However, the trend in camera tech, at least at the consumer level, is making that increasingly irrelevant. Flash and HDD based camcorders are gradually devouring DV camcorders in the lower end market. Pretty much all the HDD or flash based cameras(at least the ones that cost less than the computer they are connected to) just show up as USB mass storage devices, with one or more video files on them. Drag and drop and go. Unlike DV, where the transfer requires that X megabits per second make it from point a to point b, on time, or you'll get glitches, mass storage just requires that all the bits get from point a to point b before the user gets bored. USB still isn't quite as good as firewire at doing that; but the difference in performance is small, and the difference in price/convenience is large.
Once you get away from the real time streaming requirements of DV, to which firewire is well suited, transferring video is just a special case of connecting an external hard drive. Firewire is better there; but only modestly, which isn't really good enough to survive on the price sensitive end of things.
OSS 3 did on FreeBSD too. It's not a technical limitation of the hardware or the interfaces, it's a symptom of the NIH mentality on Linux. FreeBSD has supported software sound mixing with OSS since around 2000. I you want to play sound, just open /dev/dsp and write data there (on FreeBSD 4 and earlier you had a different device node for each virtual channel, so you needed to tell xmms, aRts and so on to each use a different one, with 5 and later the kernel does this for you). The problem with Linux sound is that, when 4Front decided to make the next OSS release proprietary, they decided to deprecate it in the kernel, rather than just maintain the open source fork. The FreeBSD folks kept developing their version and adding features, maintaining parity with the proprietary version. Now OSS4 is open source it's merged into OpenSolaris and FreeBSD has pulled in the relevant features ALSA looks both dated and nonportable, but the Linux devs have invested a lot in it so they don't want to throw it away.
I am TheRaven on Soylent News
Keeping binary compatibility limits infrastructure improvements that can be made. You're limited in what you can do to the kernel because of drivers that are sitting out there that expect binary compatibility. If we have drivers that can be loaded with little regard to the kernel version, we get into the quagmire that is Windows, where devices over 7 years old have a low chance of working. My scanner hasn't worked in Windows since XP SP1. It still works perfectly in the brand-spankingest new Linux distros.
My blog. Good stuff (when I remember to update it). Read it.
Finally ALSA adds in kernel support for creative X-Fi after 4 years, fuck creative.
Insightful?! You couldn't be more clueless.
How do you propose to fix the driver problem? The only way that gets fixed is when every hardware manufacturer writes their own drivers. That would only happen if Linux attained something like 10% market share.
In recent history (the last year or two) the majority (50.1-60%) of all commits to the kernel are drivers/driver update.
Also you forget that there isn't some company that dictates what work gets done on the kernel. There are many developers who work on areas they are want to work in. Are you telling me that linux should reject the FS brtfs because there is a non-name piece of hardware that isn't working yet?
Most kernel features will not directly effect us like driver issues.
Wrong again, My new hardware which I bought off newegg last week works fine in linux (yes I do a quick google search to make sure anyone isn't bitching about something major not working, but anyone who uses linux knows to do that). Because it works, any feature such as a file-system, scheduler improvement, or desktop memory management in low memory situations will improve my experience much more than adding a driver that I won't ever need or use.
There may have been a driver problem years ago, but today the problem is pretty much limited to graphics. And DVB, but the competition is doing just as badly there. Overall, Linux driver support is more complete than at least that of Windows Vista.
Finally! A year of moderation! Ready for 2019?