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."

Comments

Linux audio

[Anonymous Coward]

there is an equivalent of FUSE for character devices that can be used for proxying OSS sound through ALSA

That quote shows how much of a train wreck Linux audio is.

Re:Linux audio

[nimbius]

amen. OSS, alsa, pulseaudio, for christsake just give me sound that works without having a million handler processes.

OSS was okay.

Re:Linux audio

[Lusixhan]

What I've never been able to get my mind around is how Audigy sound cards frequently work out of the box in Ubuntu (for output and input), but I've never once been able to successfully capture external audio on a motherboard's onboard chipset (VIA VT1708S). Without a sound card slot available (long story) it's infuriating to have to boot into Windows every time I want to record external audio.

Re:Linux audio

[Per Wigren]

I agree but the situation is getting better and better. Pretty much every distribution has standardized on Pulseaudio and while it caused lots of problems in the beginning, and it still causes some problems on certain setups (especially with legacy, badly coded applications/games/emulators), it is a good API and it IS the future of Linux desktop audio, whether you like it or not. When this transitional period we are currently in is over, everyone will be much better off.

Re:Linux audio

[Anonymous Coward]

Duh. Exactly why?

I could understand it if we were speaking about ALSA, Pulseaudio, etc; but I don't understand why you would tell that about CUSE+OSS proxying. In the linux world OSS is an outdated API, most apps use ALSA. The in-kernel OSS compatibility layer has problems, like for example not allowing to use OSS emulation + ALSA at the same time. This compatibility layer fixes that problem, could allow to remove a lot of kernel code that didn't belong there anyway, and allows extra features that OSS traditionally can't do, like proxying the sound through the network.

So where is the train wreck? This feature not only solves a real problem, it also adds features that the 4Front stack can't do. The one people I know they will not like this are the OSS fans that hate this because it makes OSS even more irrelevant and makes their "sound mixing should be in the kernel!" argument look even more stupid.

Re:Linux audio

[sarhjinian]

It's no worse than video is, really. The four-second PulseAudio lag* matches nicely with the lack-of-vsync-based tearing in X.**

Actually, I take that back: video is worse. At least with PulseAudio I can see how it's eventually supposed to work if it didn't crash periodically. The clusterf_ck that is video playback doesn't look like it'll get fixed anytime soon, what with the six-party fight between all the various components.

You can really tell that the bills for Linux's development are being paid by server manufacturers.

* "Use jack" is not an option. Not everything works with jack.
** Yes, I know I can use OpenGL for video playback. That introduces it's own set of issues.

Re:Linux audio

[diegocgteleline.es]

Yes, because userspace sound daemons were invented by ALSA. We didn't have these with OSS, not at all....

Re:Linux audio

[bcmm]

amen. OSS, alsa, pulseaudio, for christsake just give me sound that works without having a million handler processes.

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 was okay.

OSS made it impossible to play more than one stream at once on a lot of hardware.

Re:Linux audio

[clang_jangle]

it IS the future of Linux desktop audio, whether you like it or not

As someone who does pro audio production (and has to reboot into OS X to do most it properly) that sounds like a threat to me. We've waited long enough, can we please just get back to OSS. There is no good reason not to at this point.

Re:Linux audio

[someone1234]

For some time Alsa was the "new tech". Now PulseAudio. By the time it stabilizes, there will be something else.

Re:Linux audio

[walshy007]

OSS was okay

It really wasn't, depending on your needs of course. If oss were good enough alsa would not have been invented.

Pretty much all cards are handled by alsa in the kernel back end of things, that is pretty standardised etc, the whole problem is the sound server or userspace demon that handles mixing and other bits. PulseAudio was a band aid with horrible latency, Only professional apps tend to support jack. aRts and esd at least seem to have died out when most popular kde and gnome distro's both went to pulseaudio though.

But more or less, nothing in the kernel will fix sound, it's a userland problem.

Re:Linux audio

[Per Wigren]

Please define "works". After that, imagine that some people have other needs and what the definition of "works" is in their case. Think about multiseat setups, have one users X session play audio on the front speakers and another users X session play on the rear speakers, and they have separate master volume controls. Think about using one microphone to record to several different applications at the same time. Think about logging in to a remote computer and the audio of the applications you start play on your local speakers.

Plain OSS was okay only if your needs were within OSS' very limited feature set.

The "million handler processes" are for backwards compatibility. Pulseaudio only use a single one.

Re:Linux audio

[jw867]

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.

Re:Linux audio

[Anonymous Coward]

Fscking n00bs. Please see the OSS implementation in FreeBSD for a lesson in how sound should be done.

Re:Linux audio

[miknix]

I'm using OSS4 with my Intel HDA (Conexant) Chip. I started using it to have proper audio mixing, ALSA can also do it but not every app out there is written to use the dmix plugin. In OSS4, every app that uses the (legacy) OSS API will work perfectly.

http://cafe-ti.blog.br/wordpress/wp-content/uploads/2009/02/ossxmix.png (See VMIX0 for audio mixing)

The only problem I found is that the phone jack sensing doesn't work. When I connect my phones, I'll have to manually cut-off the speakers sound in the mixer.

Re:Linux audio

[walshy007]

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)

Re:Linux audio

[Per Wigren]

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.

Re:Linux audio

[ChienAndalu]

It still is. I use it on archlinux after alsa farked up unexpectedly and it works fine.

Well, actually, not quite, the mixer is broken. But I like to pretend it isn't.

Re:Linux audio

[Anonymous Coward]

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.

Re:Linux audio

[walshy007]

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.

Re:Linux audio

[Per Wigren]

As I wrote above: 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 30-50ms latency will play through PA to JACK, at the same time even.

With the very latest versions of Pulseaudio combined with a realtime kernel (soon to be merged into the mainline kernel), Pulseaudio won't give you much latency at all. It also uses MUCH less CPU than JACK so it's much better suited for standard desktop needs. PA won't drain your laptop's battery, JACK will.

Re:Linux audio

[Hatta]

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.

Re:Linux audio

[diegocgteleline.es]

Please see the OSS implementation in FreeBSD for a lesson in how sound should be done.

Yeah, FreeBSD. And instead, why not take a look at how OS X and Windows (Vista and ahead) implement their sound systems? Hint: Both mix audio in userspace, and Pulseaudio is the closest thing to them in Linux land.

But hey, what do OS X and Windows know about desktops and professional sound systems? Nothing. That's why we all should follow the lead and use cutting-edge technology like OSS and in-kernel sound mixing.

.

Re:Linux audio

[diegocgteleline.es]

With a standard configuration, alsa does also

All the relevant desktop distros enable dmix by default...

Re:Linux audio

[impaledsunset]

"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.

Re:Linux audio

[Per Wigren]

You know what? Maybe in the future Jack will implement the Pulseaudio API and be able to function as a drop-in replacement to Pulseaudio. It's not THAT unfeasible. Also, the PA implementation is getting better and the latest versions don't have that high latency if run on a -rt kernel with realtime privileges. A bit buggy under certain conditions, yes, but that will be fixed in the future.

Re:Linux audio

[diegocgteleline.es]

not every app out there is written to use the dmix plugin.

The dmix plugin is used transparently in the ALSA libs, apps don't need to be rewritten to use it...

Re:Linux audio

[amn108]

Why mod this insightful? Just because ALSA proxies OSS, does not mean it HAS to. It is your choice, and choice is part of Linux philosophy. ALSA works fine with its own hardware drivers, without OSS involved at all. Which it usually does too. You are complaining that somebody gave you an option to use a soundcard with OSS-only mixer with ALSA applications. Where is the logic in that? It is like complaining that PulseAudio should be removed and buried because you don't use it, even though many find it convenient enough, even at the cost of increased system complexity and slightest resource usage increase.

Re:Linux audio

[Timmmm]

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.

Re:Linux audio

[Anonymous Coward]

That quote shows how much of a train wreck Linux is.

FTFY. OS X and Windows 7 *FOR THE WIN*!!!! Once again, closed source beats open source. Suck it, freetards.

Re:Linux audio

[Per Wigren]

Yes, this transitional period is pretty harsh to us who wants to run some older software that use bad coding practices. :( Thankfully, it will only get better as applications are fixed and backwards compatibility interfaces, like CUSE+ossp mentioned in the article summary, get better.

Re:Linux audio

[Anonymous Coward]

Linux was always about choices, competing technologies. If you want to be just 'given' things other OSs come to mind.

Re:Linux audio

[amn108]

They have two different goals. ALSA aims to be a generic API for interfacing a sound card. PulseAudio is a "sound server" - another layer on top of whatever API (ALSA usually) is underneath it, to provide more fine grained and desktop-worthy API to modern applications, like per-app volume control and seamless sound redirection. I welcome ideas of both, they are not competitors unless either decides to "extend" their functionality.

Re:Linux audio

[thaz]

I thought alsa was developed as a response to the OSS development becoming more closed. I've used OSS 4 for quite some time as it was the only driver available for the xfi cards that didn't blow chunks. As everything has 'just worked' I've never revisited the alsa/pulseaudio mess again. Sound in linux doesn't have to suck, sure seems like we work hard to make it so, however.

Re:Linux audio

[ObsessiveMathsFreak]

ALSA works fine, for pretty much everybody.

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.

Re:Linux audio

[TheRaven64]

You don't need them with OSS on FreeBSD and Solaris (for example), or on Linux with the out-of-tree OSS 4 implementation because they supported sound mixing so the kernel actually does what it is meant to do - lets the userspace apps ignore the differences between hardware implementations. The mixing is either done in hardware if the hardware supports it or software if it doesn't.

Re:Linux audio

[Anonymous Coward]

Leaving out audio (*) care to elaborate which video player you use?

'mplayer' mostly worked for me. Though as usually I periodically experience A/V sync problems (**) it still better than VLC or Xine.

(*) Hurrah!!! KDE 4.3 is the first DE properly recognize and use my two sounds cards!!!! I can finally adjust the volume!!!!! On other note, rest of applications (95%) is as broken as ever. Mplayer included.

(**) Which IIRC caused by fact that Linux still doesn't have any real-time timer service available to user applications because - UUUH! *SCARY*!! - it might cause DoS when used improperly.

P.S. Mac OS X approach I find superior. Instead dumbly, akin MS, claiming "but we do not know what applications might do!? so we will not provide any decent interface period", Apple came out and made APIs for particular tasks: CoreAudio, CoreVideo and CoreImage.

Re:Linux audio

[Anonymous Coward]

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).

Ever since 1.0.14, which was released over 2 years ago, dmix is automatically set up. You normally don't have to touch asoundrc by hand unless you want special routing of channels.

Re:Linux audio

[bcmm]

Except Windows apps usually don't break just because there is a new flavor of the month in terms of audio.

What apps broke? OSS apps are broken, in that they hog the soundcard. They used to do that under pure OSS too.

Re:Linux audio

[loufoque]

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

So application-level mixing is strange? To me that's a basic feature every desktop should have.
Being able to reduce or shut the sound of a single application is priceless.

Re:Linux audio

[TheRaven64]

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.

Re:Linux audio

[keithjr]

Pretty much every distribution has standardized on Pulseaudio

This really doesn't matter until application developers do the same thing. If devs continue to not use higher-level APIs like SDL, every program is still going to vie for different resources in different positions on the stack. At some point, the Linux community has to lay down the law and break backwards compatibility for the sake of enforcing real standards.

Re:Linux audio

[bcmm]

If Ubuntu didn't package the ALSA driver you needed, that is a problem with Ubuntu, not ALSA (unless you built them from SVN or something).

Re:Linux audio

[Rynor]

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).

Like per-application volume control that no other OS provides (except Windows Vista and higher, Mac OSX, etc)?

Re:Linux audio

[Carewolf]

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.

Re:Linux audio

[Anonymous Coward]

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.

Check list of Linux kernel contributors to understand why.

Do not know how it is now, but in past one could see lots of ignored/rejected patches on lkml with desktop relevant changes.

Re:Linux audio

[bcmm]

Correction to the above: ALSA enable dmix by default. It takes a distro or user to purposefully disable it.

Re:Linux audio

[TheRaven64]

No, there is one goal. Userspace developer wants to play and record sound without caring about the details of the hardware. This is quite a simple requirement and OSS handles it well on OpenSolaris and FreeBSD. The new API is a step in the right direction. Now developers can use the standard, cross-platform, OSS APIs (which are really simple to use, just use ioctls and don't add any library dependencies) and Linux can implement them via its typical twelve layers of indirection.

Re:Linux audio

[Carewolf]

You don't need pulseaudio. It is just a GNOME audio daemon that is many times better than esd, but still crap.

Re:Linux audio

[BrokenHalo]

That's sort of why I just keep using my old Audigy 2 ZS. I haven't actually had any problems as such with most other on-board chipsets, but the Audigy cards in most of their various incarnations are just so damn good. The main reason I bought mine was to digitise my old vinyl LP collection - a project which is still ongoing.

At the time it gave the best bang for your buck in 24-bit sound, and I've never regretted it since. Of course, sooner or later I might find myself stuck with a motherboard without any PCI slots, in which case I'll be in trouble...

Re:Linux audio

[StayFrosty]

If by "Flavor of the month" you mean "flavor of the last 5 years" I might agree. OSS was marked deprecated in the kernel tree when 2.6.0 came out. Luckily, ALSA--which has been the audio implementation that has been standard since then--supports OSS emulation. That way old OSS apps still have working sound.

The fact that it is 2009 and there are still audio issues on Linux is telling, however.

The problem isn't with Linux, it's with old, unsupported applications taking exclusive control of the sound card (Teamspeak, I'm looking at you.) This new feature should help fix that problem while still maintaining backward compatibility.

Re:Linux audio

[Chrisq]

there is an equivalent of FUSE for character devices that can be used for proxying OSS sound through ALSA

That quote shows how much of a train wreck Linux audio is.

I wouldn't disagree with you on that, however this is actually doing something to mitigate it. If a user can proxy one sound system through another without having to install kernel drivers it has to be an improvement.

Re:Linux audio

[jabjoe]

Where do you think is the fastest place to process, kernel or userspace?
Do you want fast audio?
Want network sound? Do it properly, with X, http://www.chaoticmind.net/~hcb/murx/xaudio/
Don't put sound and video through completely unrelated paths.

Re:Linux audio

[MrNaz]

Is there a reason that we can't now back up this crashed truck and point it in the right direction? Obviously the current approach doesn't work, can't we go to Linus, say "hey, we tried it your way and got nowhere, can we do it right now?"

If doing sound mixing in the kernel is the "right way", then I hope Linus is man enough to admit his error...

Re:Linux audio

[BrokenHalo]

The fact that it is 2009 and there are still audio issues on Linux is telling, however.

The simple fact is that for most people there are no audio issues. The majority of name-brand chipsets do what's most usually needed out of the box on most sane distributions.

If you need your hardware to do strange or recondite things, then it's perfectly natural to have to look further. That applies just as much on Windows as anywhere else.

Re:Linux audio

[MrNaz]

They won't do this, and they'll forward all the same arguments that MS uses to explain the reason that the Windows APIs require backwards compatibility and can't be broken.

I'm absolutely totally pro-Linux. I use it all the time, but what's good for the goose must also be good for the gander.

Re:Linux audio

[Hurricane78]

But Pulseaudio is a piece of shit! Especially for making music. It's another pointless layer of inner platform. Just as all those others. Like ESD, arts, etc...

We need OSS4 in-kernel, plus proper and simple Jack integration and configuration from the start. That's it.

Then *everything* else can go to the trash. :)

Re:Linux audio

[Xaemyl]

... until there's a schism that causes a fork. :P

Re:Linux audio

[shentino]

Doing sound mixing in the kernel is probably the easiest way to do it if you want it to be hardware accelerated.

Re:Linux audio

[BrokenHalo]

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.

Well, that should stand to reason. If you upgrade your kernel, the modules you built for your old kernel won't work (they usually can't even be found by the new kernel unless you force it).

I've always built my own kernels (heavily stripped down, because I'm that sort of person), and I haven't needed to rebuild ALSA separately for a very long time - like I can remember doing it, but I think not less than about 7 years ago, at some point when new ALSA releases were a bit behind in inclusion with the kernel. Back in the days when I first started playing with Linux (about 1995) sound was often a problem, and OSS was right in the middle of it. There are lots of reasons why OSS has been deprecated since, and I don't miss it one bit.

I'm curious as to what chipset your sound system is.

Re:Linux audio

[RiotingPacifist]

That can (and IMO should) be handled by alsa. No app should have to worry about anything put pushing its waves out. The real benefit of pulseaudio is apparently the powersaving (ironically called glitch-free audio), but that should IMO defiantly be in the kernel.

Re:Linux audio

[Tubal-Cain]

Like per-application volume control that no other OS provides?

The applications themselves provide that.

Re:Linux audio

[bluefoxlucid]

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.

Re:Linux audio

[keithjr]

I'm pro-Linux as well, don't get me wrong. But I still think that if Windows had something as fundamentally broken as sound is in Linux, they'd crack down. A good example is the (much-derided) UAC in Vista: the overwhelming majority of Windows applications attempted to use an inordinately high level of access privilege, so MS added a nag. Not the most graceful method, but it set a fire under community's collective feet to convince them to make smarter use of the API.

Re:Linux audio

[diegocgteleline.es]

Where do you think is the fastest place to process, kernel or userspace?

The CPU doesn't run magically faster when it is running kernel code...

Re:Linux audio

[setagllib]

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.

Re:Linux audio

[diegocgteleline.es]

You don't need them with OSS on FreeBSD and Solaris (for example), or on Linux with the out-of-tree OSS 4 implementation

You don't need them in ALSA either, because dmix is implemented in the ALSA library, not as a userspace daemon.

It's amazing the increible amount of FUD that has been spread about these topics...

Re:Linux audio

[Anonymous Coward]

OSS was okay

OSS was abandoned by the company behind it, they wanted to sell their commercial version instead. There were no maintainers for OSS. It had woeful support for cards around at that time, only supporting simple old stuff. No one was prepared to step up and ALSA, a far more flexible alternative took over. However, latency was an issue for those doing DAW, and JACK wasn't still in its infancy.

Re:Linux audio

[walshy007]

"Use jack" is not an option. Not everything works with jack.

serious question, what didn't you manage to get going with jack? with a bit of tinkering I can get pretty much everything going, initial setup from pulse audio is a bitch though.

Re:Linux audio

[loufoque]

That can (and IMO should) be handled by alsa.

And the kernel developers don't agree, and for pretty good reason.
This is not part of the hardware abstraction. The fact there is software mixing in ALSA itself is already controversial enough, but needed to have a common ground between cards that support hardware mixing and those that don't.

No app should have to worry about anything put pushing its waves out.

I don't understand how that is related at all.

Pulseaudio simply provides a control panel that allows you to control the volume of every audio stream connected to the daemon.
ALSA can't and shouldn't do that. That's definitely the job of an user-space daemon.

Re:Linux audio

[bluefoxlucid]

The kernel does not magically get 600MHz more CPU, you failed first-level compsci drop-out. Kernel space is where latency paths are cut short; everything context switches to the kernel, then memory gets copied(!) from userspace at page-granularity, then work gets done. In user space, sockets can stream arbitrarily short (hundreds of bytes instead of 4k blocks) blobs of data, or zero-copy pages shared between applications, with an application context switch into the server. In either case, the same processing happens; but we can zero-copy the application level case, allow better real-time system response and prioritization, and make scheduling adjustments that allow more smooth overall real-time operation by scheduling hardware-interacting application processes properly rather than kludging around with scheduling a kernel thread to yield and wake on the side of this same scheduling policy.

Re:Linux audio

[Anonymous Coward]

he Linux devs have invested a lot in it so they don't want to throw it away.

Duh, Linux prefers to follow the lead of Windows and OS X -userspace sound mixing- rather than follow the example of BSD and Solaris which, mind you, they don't know a lot about sound...

Re:Linux audio

[Anonymous Coward]

It very much is a technical limitation of the hardware. One which can and should be dealt with by the software stack. If you want to play multiple streams through the same output then there is going to have to be mixing somewhere. Either the hardware can do mixing or it can't. Certain Soundblaster Live or Audigy cards can for example but its rarer these days. Add to that that you would like to dump whaever format your audio data is in to the audio device and not worry about sample rate conversions, mu-law to a-law, signed or unsigned. Solution: some interface that will take advantage of your hardware where it can and do the rest in software.

Now you don't want to do floating point in the kernel - strict no no on Linux, so pushing some part to an outside helper is ok. But for heavens sake give me ONE interface. OSS was the first one size fits all that was useful, actually a nice API from a programmers perspective. Somewhat limited with the newer hardware that came out, so we got ALSA. Which was just Linux, and has an API you'd rather beat to death with a stick. Esp. the mixer one. They both failed to provide the software mixing when coming on the scene (now they do, mostly) so you ended up with all these daemons - arts, esd, and I'll consider pulse audio another one. Multiple APIs, horrid configuration - its a nightmare. I might use ALSA to provide /dev/whatever but I always code against the OSS API. When I built my current PC the motherboard 24bit surround sound is no good to me because ALSA softare mixing didn't work for the OSS path. Ended up having to find a Soundblaster Audigy 2 to get hardware mixing! Convincing ALSA to order the OSS sound devices right was a kernel module parameter tweak. Otherwise it prefers the onboard line outs or HDMI port to that dedicated sound card :( Why should this still be a problem in 2009? I wouldn't miss ALSA one bit.

Re:Linux audio

[sarhjinian]

Depends on the day of the week, the format and who's using the computer. I have the most luck with VLC outputting to either Xv (if I care about quality) or OpenGL (if I care about tearing and/or have Compiz turned off) and putting audio natively to Pulse. mplayer gets used for more esoteric files, but the interface (even with SMPlayer) is not great. Xine's not so hot either. My spouse uses VLC for the most part after getting thoroughly disgusted with Totem. Trying mplayer on her wasn't a success.

It works, more or less, but it took more experimentation than I'd like to get it all working. The horrible part is that hacking MacOS onto the same hardware more or less just works. No tearing, no audio quitting, just the occasional stutter on the more demanding files.

Video tearing is what gets me. That shouldn't happen: it should be easy to sync to vblank, but the very way X works makes it very, very hard to do without some other kind of sacrifice (eg, using OpenGL, which then gives you trouble with compositing)

You're right about Apple's approach, especially for desktop stuff. Video playback is seamless: rarely any stuttering or tearing and no problems with video conflicting with compositing. Audio works well, too: I don't recall the last time I saw a Mac app kill audio or suffer mixing stupidity. Apple made some very smart design decisions in how OS X handles these; the emphasis being on things users notice, like "Volume should be consistent", "Video should never tear", "Windows should never leave crud/blank out when dragged/etc".

As far as I can tell, the last year and bit have been a worse-than-usual time for Linux on the Desktop. Video support is in a problematic state of flux: everything seems to be changing (KMS, DRI/DRI2, XAA/EXA/UXA, Xv, Mesa, X itself, the binary drivers, new open-source rewrites of drivers, the kernel) all at once. Audio is similar: there's the cleanup from Pulse's impact, there's old apps that still use OSS or ALSA (and do so badly, thanks Skype and Flash!), there's a proliferation of bugs in ALSA, HDMI audio and then there's effort still being expended on getting ALSA and OSS to do what Pulse or Jack is supposed to do.

It looks like it'll all settle down in a year or so, but the interregnum is not pleasant. The worst part is there's people in this who seem to be hell-bent on making things worse before they get better.

Re:Linux audio

[Carewolf]

Removing the fat from PulseAudio would be removing PulseAudio in most cases. It could still serve as an audio-proxy for rare networked cases, the API would be good for those cases. Right now ALSA defaults to using dmix, which means that you don't really need an audio-server, it is just useless bloat most users really dont need. The days of sound-daemons belong to aRts and ESD, and those days are over. For some reason this anachronistic abomination called pulseaudio just wont die.

Re:Linux audio

[walshy007]

What IS the PA latency, and the Jack latency?

as with all things, depends on your setup, but a good jack setup can go as low as 4msec, pulseaudio seems to be around 50msec or so.

Do the mixing in your application and output it to ALSA.

And your proposal to have multiple sound applications interact is?

"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.

Err... you seem to be implying that there is an analog audio in that these people are using the pc to record and play back... almost never the case.

These people are sequencing midi on the computer, and rendering it to sound with custom synthesizers. After about 16msec you can HEAR the latency, 50msec is just useless. The workflow you described works well, for analogue, but it just is not the kind of work these people are using their computers for.

Re:Linux audio

[sarhjinian]

Flash.

Yeah, yeah, I know, but it's not really an option to avoid it and/or download files and play them later. Skype would be the next one. I got it working, but it was nastier than doing the same in PulseAudio was. The final blow was getting my Apple Airport's audio working. Pulse got this (more or less) working more or less. I like the premise of jack, but it seems like it'll be relegated to second-fiddle status and that anyone who uses it will end up running it side-by-side with Pulse, doing pro work while Pulse does everything else.

Re:Linux audio

[walshy007]

accidentally forgot, reference on how the audio latency effects midi users, here they claim you can usually hear above 6msec, but most people don't seem to notice until about 16 or so, still 50msec is almost 4x that

Re:Linux audio

[bluefoxlucid]

I can and have sequenced Midi manually, and then recorded the output from a software synthesizer directly, and then merged it with other tracks built in i.e. ModPlug Tracker or Cheesetracker or whatever other cheesy tracker software I've gotten.

Even with something really low-end, you see the problem: the MIDI tracks get way out of sync with the sampled tracks, and it sounds like garbage. It takes very esoteric efforts to fix this, and then you have i.e. 20mS latencies within the soundfont processing crap of the sound card, or within the hardware driver; or HUGE (120mS) latencies in software synthesizers like SWXG-1000. Everything gets way out of sync.

And then you go, "Huh, that's irritating. I guess I have to record these things separate, and then align them in Audacity." Then you wind up adjusting them with stereo effects, adjusting the levels for each track, and merging; this process is called mastering, it's a high-level professional technique I independently invented (i.e. it was popular but I came up with it on my own without knowing about the industry) in my parents' attic when the Internet was just starting and I was 10. It's that simple and easy to figure out, so I must assume everyone else is a complete retard or a whiny lazy bitch.

And I'm not even a sound engineer...

Re:Linux audio

[Anonymous Coward]

Not only that, but OSSv4 boasts almost all the same features as Pulse Audio, but without breaking your sound like Pulse Audio.

To be perfectly honest, sound in Linux worked quite well for a long time with just ALSA. Nobody really complained about sound anymore. And then some idiot thought introducing Pule Audio as a default in major distributions was a good idea, causing probably the biggest sound regression in Linux history.

I've experimented with ALSA, PA, and OSSv4 on Arch Linux. ALSA just worked. No real sound conflict or anything. But ALSA is rather lacking in enhanced features an audiophile might like. Easy to get set up, though. Basically installing the userspace tools, unmuting your ound channels, and saving that state. Bam! Done. This setup is enough for most users.

Pulse Audio did not want to work. I followed the best setup and fixit HOWTOs I could find, but they only seem able to reduce the problems Pulse Audio has. And sadly, PA's developer and its apologists seem to love blaming the crappy sound support Pulse Audio has on ALSA or its drivers. However, seeing as how just about all the other sound daemons before and after PA's advent have had no problems with ALSA, I think the truth is that Pulse Audio is just garbage that is far from ready.I could not remove it fast enough.

Now... OSSv4 set up like a dream. A little more complex than ALSA or PA to set up, such as blacklisting soundcore. But it didn't take any actual configuring. And what was nice was all the features we apparently "needed" from Pulse Audio (Honestly, we didn't need PA at all. ALSA has been adequate for a long time.) are there. The problem I saw though is probably OSSv4 supports less sound chipsets then ALSA.

I think Pulse Audio's main problem though is that its a sound DAEMON (Akin to JACK, ESD, or Phonon. In fact, I hae it on good authority that it is about to replace ESD on GNOME.) that wants so hard to be a sound SYSTEM (The low-level grunts like ALSA or OSS. Again, on good authority, I believe that unlike OSS or ALSA, Pulse Audio doesn't have drivers for specific sound cards to truly pass itself off as a drop-in replacement for ALSA or OSS. In fact, it needs plugins to actually route its "sound processing" to the real sound system. No, my friends, PA is just a sound daemon written by a guy who despises ALSA.) and thus messes up being both.

Re:Linux audio

[drinkypoo]

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.

There is a current trend of cheaper, lower-power-consumption hardware. I am typing this on a Gateway LT3103u, with a 1.2 GHz Athlon 64 and a 300MHz ATI integrated GPU. The machine is a little less power-efficient than its Atom-based cousins, but is substantially speedier than a 1.6 GHz Atom for most tasks. Allegedly going to a lower-latency SODIMM will get me a 5-10% performance increase; there has been some success with overclocking as well. As peppy as this machine is (720p flash video supposedly chokes, but it can handle 720p mpeg4) I want the hardware to do the heavy lifting at all times!

Re:Linux audio

[drinkypoo]

If I could find a realtime kernel that didn't make my hardware shit itself I would be overjoyed. I've tried Ubuntu's -rt kernels on IBM eServer 325, on HP EliteBook 3725w (is that right? probably not. Core 2 Duo T9400, nVidia Quadro 2700M, whatever it is), on Thinkpad A21p, and on my Gateway GT5475 nForce/Athlon 64 X2 4000+/nVidia 8600GT system, and it makes all of them shit themselves, e.g. hard lockups. Adding in pulseaudio in realtime mode only makes the situation worse.

Re:Linux audio

[Desler]

A bit buggy under certain conditions, yes, but that will be fixed in the future.

Except this is the exact excuse we get countless times when audio, video, etc don't work in Linux. Just give us more time! We swear it'll work in the future! Then you wait 6 months and all that previous work is scrapped and something new is built. Then we're told again: Just give us more time! We swear it'll work in the future! Lather, rinse, repeat.

Re:Linux audio

[Anonymous Coward]

I see, so now the PA people are expecting people to compile custom kernels to compensate for the crappiness that is Pulse Audio instead of, I don't know, FIXING Pulse Audio like a responsible developer?

Face it, Pulse Audio is a stupidly bad sound implementation no one needs.

It's not ready, period. And the attitude of PA's developer (Blaming all of PA's problems on just about everything but PA.) suggests to me we'll NEVER see a complete Pulse Audio that works like ALSA or OSSv4.

Re:Linux audio

[shutdown -p now]

Now if dmix was also always properly configured out of the box...

Of course, the problem with ALSA isn't the lack of mixing. The problem is braindead API and overcomplicated configuration. Another problem is that it's not cross-platform.

Re:Linux audio

[miknix]

Like per-application volume control that no other OS provides (except Windows Vista and higher, Mac OSX, etc)?

Wrong. OSS4 provides per-application volume control. Now check where OSS4 and append some more OSs to that list.
Pulse-audio can also do per-application volume control.

If you are still in doubt, look at this OSS4 mixer (vmix0):

http://cafe-ti.blog.br/wordpress/wp-content/uploads/2009/02/ossxmix.png

or the mixer for pulse audio:

http://fedoraproject.org/w/uploads/8/82/Interviews_LennartPoettering_PulseAudio.png

It is good and informative to say certain list of things does X.
It is totally wrong and will take all your credibility away when you say certain list of things is the ONLY that supports X, specially when you show no apparent knowledge or basis to support that certainty.

Re:Linux audio

[miknix]

You are right, thanks for the clarification.

What I meant is that ALSA uses dmix for audio mixing and there are some apps out there still written for OSS that need to be rewritten for ALSA.

Re:Linux audio

[ultrabot]

I think Pulse Audio's main problem though is that its a sound DAEMON (Akin to JACK, ESD, or Phonon.

Phonon is not a daemon, it's a library.

Re:Linux audio

[Anonymous Coward]

BS. I have two audio cards (one on MB, another PCI). Never ever had any problem with Windows. Similar experience on Mac OS X with built-in audio and extra USB speakers - not once had I a problem. "Just Works" (c).

It's only on Linux you simply have no reliable interface where you can on the fly change audio card.

Heck even with ALSA, the most reliable interface on Linux, one has to drop to command line just to change default sound card. And restart everything afterwards for the change to take effect. How more moronic it can get?

P.S. And no PulseAudio please. It's fine for flash video/etc, but it sucks terribly at movie playback.

Re:Linux audio

[walshy007]

that's a lot of heavy post-processing for a problem which if you use modern technology and something with low latencies you really just won't have to deal with at all at that stage

The main difference in our opinions though comes from the rather different way you're doing things, which is a great deal more difficult and might have been necessary a decade ago.

Prime example is the idea of loading soundfonts on to a sound card, it isn't done that way these days for a myriad of reasons, pci bus latency being a main one. Flexibility another. Hardware midi with soundfonts on a sound card isn't even seen as something beneficial now.

These days everything is integrated, volumes for individual tracks etc are adjusted easily even in midi form while you're working on it and playing with it. no need to render it to a fixed saved waveform until you're completely done, it can do whatever you like in real-time.

Even with something really low-end, you see the problem: the MIDI tracks get way out of sync with the sampled tracks, and it sounds like garbage. It takes very esoteric efforts to fix this, and then you have i.e. 20mS latencies within the soundfont processing crap of the sound card, or within the hardware driver; or HUGE (120mS) latencies in software synthesizers like SWXG-1000. Everything gets way out of sync.

with the 4msec jack latency i mentioned, with everything as it should be that's all the latency you'll ever get. (ok to be pedantic you could maybe add 1msec for usb polling for the midi device you're using if you are) This is an advantage of the heavy integration of everything.

Mastering pre-done waveforms is still a handy skill of course, chances are you'll deal with analogue instruments at some stage. But might i heavily recommend you look into some of the more modern ways of making music electronically? things aren't what they were like a decade ago, where what you have said would have been necessary

Re:Linux audio

[kayoshiii]

Actually you can Run KDE on top of jack - since Xine (and therefore phonon) now has a jack backend.

Re:Linux audio

[Anonymous Coward]

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.

Agreed! And This is a scarier diagram for the X Window System, yet nobody complains about graphics on Linux, just sound!

Re:Linux audio

[Hatta]

It's not a technical limitation of the hardware or the interfaces, it's a symptom of the NIH mentality on Linux.

If the BSD folks didn't bitch every time linux used some of their code, maybe that wouldn't be a problem.

Re:Linux audio

[xiando]

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.

My athlon2k system recently failed and fetched a pentium3 633mhz from the basement and installed Ubuntu on it to use while I waited for my new desktop box. Ubuntu insists on running everything through pulseaudio by default. I was shocked to find that this box had problems playing xvid movies and ran top. There pulseaudio was, using 20% CPU and it insisted on doing that even when I ran mplayer -ao alsa. Removing this junk allowed mplayer to play xvid videos smoothly. Perhaps those who have rare old soundcards without hardware mixing and do not want to setup alsa's dmix benefit, who knows, but I do know I did not. Perhaps pulseaudios insane CPU usage is less of a problem with modern hardware, but there is no soundcard made this century that I know of who does not do hardware mixing, so why anyone would want this junk -- specially installed by default on a distro -- is beyond my understanding.

Re:Linux audio

[Anonymous Coward]

IMO per-application volume control is a worst feature ever. I had it once under Windows (was feature of driver) and it was more confusing than helping.

Re:Linux audio

[bluefoxlucid]

that's a lot of heavy post-processing for a problem which if you use modern technology and something with low latencies you really just won't have to deal with at all at that stage

"Modern Technology" requires a specialized OS and specialized software to "almost" get it right, "sometimes." Sure, Jack has 4mS latency... and your software synthesizer isn't instantaneous either... and your IRQ bus has to pass things around... and then it has to come out your PCI bus. In the end, you're like 20mS or 50mS behind; but you're say 37mS +/- 3mS, so you think everything has 4mS or "no" (observable) latency. This is all very wobbly, but whatever; as long as it's all within $X of each other and the total real latency is lower than $Y, it's fine.

Remember "can" and "should" are two different things. The only advantage low-latency real-time stuff gets me is the ability to play back changed MIDI streams with sampled streams etc etc to preview my final rendered changes. This comes at the expense of trying to actually get those tiny latencies, and finding it strange, unfamiliar, and difficult to deal with when you can't (many people just find this "unusable" and replace the whole system). Oh, and you need a faster processor to do more complex things, and more RAM.

The main difference in our opinions though comes from the rather different way you're doing things, which is a great deal more difficult and might have been necessary a decade ago.

It's how professional mastering is done today for real bands. I daresay it's also not too hard; hell, I could dole out stuff BassHunter does from Modplug with a software synthesizer (i.e. I'd have to write a new feature that emulates a KORG or MOOG synth platform) easily, on a slow, latency encumbered system. Even MIDI "recording" can be done with a keyboard and a monitor (headphones), and then time-shift (remove delay) the beginning of the whole recording, as long as playback is SMOOTH.

I find none of this particularly difficult. An extra step at some point, and trouble when you're mixing real-time output from multiple programs and external hardware (MIDI rack-mount synthesizer, a KORG, a MOOG, etc) together; but that's hard stuff to get synchronized anyway, and I'd rather pre-record my lines from each blob of hardware/software than mess with that crap.

Prime example is the idea of loading soundfonts on to a sound card, it isn't done that way these days for a myriad of reasons, pci bus latency being a main one. Flexibility another. Hardware midi with soundfonts on a sound card isn't even seen as something beneficial now.

Yes, I mentioned that there's soundfont crap in the hardware driver, i.e. instead of letting a coprocessor do the work with $MEGABYTES loaded to sound card and $BYTES sent to it, we use the CPU to render $MEGABYTES and transfer it over the PCI bus to the sound card. Just moving the latency around and inflating the bandwidth usage.

These days everything is integrated, volumes for individual tracks etc are adjusted easily even in midi form while you're working on it and playing with it. no need to render it to a fixed saved waveform until you're completely done, it can do whatever you like in real-time.

Yes, this is true. I don't think any software allows you to adjust individual sources (or tracks even) for latency, i.e. tell it your MIDI device has 20mS latency and your direct WAV output has 0mS latency, and let it auto-correct everything. This would be useful.

Even with something really low-end, you see the problem: the MIDI tracks get way out of sync with the sampled tracks, and it sounds like garbage. It takes very esoteric efforts to fix this, and then you have i.e. 20mS latencies within the soundfont processing crap of the sound card, or within the hardware driver; or HUGE (120mS) latencies in software synthesizers like SWXG-1000. Everythi

Re:Linux audio

[Anonymous Coward]

the userspace demons enter it all

some of the sound demons do add some nice features

another reason why these demons were made.

I knew it! You Lunix hippies are just a bunch of sick devil worshippers.~

Re:Linux audio

[Anonymous Coward]

So, my audio leaves my application, goes through Pulse Audio, then through Jack, then through the ALSA layer, then to the kernel?

Why the heck doesn't ALSA just mix multiple streams? Talk about classic BS bloat.

Re:Linux audio

[TheRaven64]

BSD folks don't bitch when Linux folk take their code. There is lots of BSD code in Linux. They bitch when Linux developers violate the license by removing the BSD copyright text and slapping a GPL on top of the files.

Re:Linux audio

[icebraining]

My card has that chip too, and I coulnd't configure dmix to work properly, so I switched to OSS4, but besides jack sensing, it lacks proper support for hibernation, so I have to restart the sound drivers each time I resume. I can automate it, but if any audio program is open it doesn't let me restart the driver.

Re:Linux audio

[Hatta]

Yet they are curiously silent when commercial entities release derivative works under their own license.

Re:Linux audio

[bendodge]

I am an amateur "sound engineer", if you will, doing stuff for a religious institution. I hate electronic music with a passion. There is no substitute for a real violin. I'm a big fan of making music the old way. Have everyone play/sing with a metronome or each other until they get it right, then mix it at your leisure. If it's live, you just mix it on a real mixer.

I cannot enjoy listening to synthesized music. It sounds cheap. Like you couldn't afford to have real instruments, or you were in too big of a hurry to do it right. I also hate hearing voice processing. If you can do it well enough that I can't tell what you did I've no grounds to complain, but that's another topic.

I hope "real instrument you have to learn to play" classical styles come back soon so I can stop being bombarded by electronica everywhere I go without earplugs.

Re:Linux audio

[Anonymous Coward]

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

I agree. There is a trend toward new sound devices being very non-accelerated; lots of devices can only accept 48k sampling rate, have no hardware mixing features, and only accept a single sample size (24 bit usually).

It's similar to how early modems were completely self-contained little computers by themselves, and later "soft modems" had a bare minimum of hardware and figured you should do the rest in the driver.

PulseAudio has been painful, especially in my favorite distro (Ubuntu) but overall I think it is the right idea, and I think most of the pain is past. Using CUSE to send OSS through PulseAudio is the correct way to go AFAICS.

Re:Linux audio

[miknix]

Yeah, that is true.
But have a look to the soundoff script, you can add a couple of lines there to kill applications using the audio device instead of just showing up a warning like it does by default. This will help you automate it.

Also, if your firmware is capable of generating a ACPI event during suspension/hibernation, you might be able to call your ossoff/on script there automatically.

Oh and by the way, you can also get which apps are using the audio device by:
lsof -w /dev/dsp*

Here, I only have to care to *not* let firefox opened with a flash plugin active or firefox (along with a crapload of opened tabs) will be killed when I suspend the laptop :)

Re:Linux audio

[Profane MuthaFucka]

Old applications like the ancient VMware 6.5.3.

When will those cocksuckers switch to ALSA?

Re:Linux audio

[Anonymous Coward]

Pretty much every distribution has standardized on Pulseaudio and while it caused lots of problems in the beginning, and it still causes some problems on certain setups...

Thankfully, I use gentoo and avoiding pulseaudio has been as simple as USE="-portaudio" I've also pulled in OSS4 from an overly, so I now run with USE="-alsa" as well. Now none of my apps have any strange audio issues at all, and the mixing is of a higher quality than what alsa provided when I used to use it. Linux is usually great, but there's no doubt in my mind that the BSD guys did the right thing by sticking with and building up their OSS implementation rather than jumping ship with an entirely new sound system, but I suppose Linus' strange opinion on in-kernel audio mixing is really the problem.

Re:Linux audio

[TheRaven64]

No, they also complain when commercial entities release products that don't respect their license. Most BSD code uses the two-clause license, so it's not hard to avoid violating the license. As long as you keep the copyright notice intact, you can do whatever you want with it. When you break a license that is that easy to follow, it's pretty obvious you've acted in bad faith, so don't be upset when people complain.

Re:Linux audio

[onefriedrice]

but I suppose Linus' strange opinion on in-kernel audio mixing is really the problem.

It would be nice if Linus would ever admit that he's wrong. I mean, okay Linus, you made a mistake. It turns out that mixing works out better in the kernel. We don't think any less of you just because you made a mistake, so just change your opinion, allow OSS4 into the kernel, and we'll all move on. Actually, we think a lot less of you every time you're too sissy or big-headed to admit you're human.

Re:Linux audio

[Rynor]

I know OSS4 provides this feature, but we were talking about ALSA ;)

Re:Linux audio

[miknix]

Sorry, my fault then :)

Re:Linux audio

[kelnos]

PulseAudio was a band aid with horrible latency,

I suffer no latency problems with PA. How is it a band aid? It's the way of the future, as long as proper software mixing and control is kept out of the kernel. PA gives Linux a decent audio API, starting to approach the kinds of things you can do on Windows or MacOS.

Only professional apps tend to support jack.

Because jack solves a problem that has nothing to do with regular ol' desktop audio.

Feel free to read up on things so you understand them before posting. PA and jack can coexist (and the developers of both have been working together for some time now to ensure this is so), and solve completely different problems.

Re:Linux audio

[kelnos]

I'm sorry you have shitty drivers for your audio hardware, but cutting in PA as default for several distributions was a calculated move designed to quickly expose these sorts of problems so they could be fixed in the audio drivers themselves (PA exercises the ALSA API in many different interesting ways that most apps don't).

If you object to the idea of your distro using you as a guinea pig, I can certainly understand that, but that's a separate issue.

Re:Linux audio

[Per Wigren]

So, my audio leaves my application, goes through Pulse Audio, then through Jack, then through the ALSA layer, then to the kernel?

If you are using pro audio apps at that specific moment, then yes. Otherwise you don't need JACK.

Why the heck doesn't ALSA just mix multiple streams? Talk about classic BS bloat.

It does (with dmix), but it doesn't support per-application volume settings, on-the-fly detection and configuration of things like bluetooth headsets and networked speakers, on-the-fly routing of audio (master or application specific) to different or multiple sets of speakers and a lot more. Also, ALSA is Linux-specific whereas Pulseaudio will run on any UNIX, Windows and MacOS X. Do you have a better idea how this should be handled while being as flexible?

Re:Linux audio

[Anonymous Coward]

FreeBSD OSS is kind of ... weird I might say especially for the upcoming 8.0 release. They outdid official OSS4 in various parts: ac3 passthru even with virtual channel mixing enabled, bitperfect, state of the art sampling rate converter (just take a look at http://people.freebsd.org/~ariff/z_comparison/ , etc. etc..)

Truly dramatic :-)

Re:Linux audio

[Per Wigren]

there is no soundcard made this century that I know of who does not do hardware mixing

How about HDA and AC97 used in about 95% of the computers built in the last 10 years?

Re:Linux audio

[TheBig1]

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

Re:Linux audio

[Ant P.]

OpenAL looks nice on paper, but the only two options for it right now are the software driver (which has actually improved a lot recently) or a closed source train wreck for Creative's cards. If you thought fglrx was bad, you've seen nothing yet. You'll probably hear nothing too.

In an ideal world the OpenAL spec would be like OpenCL - designed to work with OpenGL so you could effectively say to the driver API "draw this room, oh and render this pcm sample at (x,y,z) and stream it to the sound card".

Re:Linux audio

[Anonymous Coward]

It seems to me you've assumed that we all have some other way of hearing all the pre-recorded tracks (usually recorded or at least saved/downloaded onto the very same computer, no less). Should we move them somewhere else first? Perhaps to a tape recorder? Or are you advocating nobody listen to backing tracks when they sing or play?

I think, as other posters have pointed out, there's a distinct difference in process. You seem to me to only address one situation, but there are many others.

For instance, my laptop is my complete audio workstation. I have no other gear. No offboard mixer, monitors, etc. If I can't be reasonably expected to create electronic music in my basement on one computer, completely digitally, in this day and age then I give up on music tech.

Re:Linux audio

[alext]

Is there a purist option which would allow me to flip between merging sources via mixing/resampling and letting the bitstream through to the digital output unmolested (e.g from a FLAC file)?

Part of my confusion is that I don't know how volume is supposed to work with digital outputs - is the mixer supposed to simply reduce the amplitude or does it encode a separate volume setting in the PCM stream?

Ta for any info - I've looked but not found anything in the PA docs.

Re:Linux audio

[Ant P.]

hell, I could dole out stuff BassHunter does from Modplug with a software synthesizer (i.e. I'd have to write a new feature that emulates a KORG or MOOG synth platform) easily, on a slow, latency encumbered system

Wouldn't it be much quicker and less painful simply to pour lava into your ears?

Re:Linux audio

[RiotingPacifist]

Pulseaudio simply provides a control panel that allows you to control the volume of every audio stream connected to the daemon.
ALSA can't

alsa can do this with dmix and softvol.

and shouldn't do that. That's definitely the job of an user-space daemon.

even if you can do it with hardware mixing?
90% of the time even under pulse audio you are not using any of the user-space mixing, you just passing plain streams straight to hardware. The kernal guys have said they don't like the complex stuff going on in kernel, so push it back out if required, yeah its a bit ugly for that last 10% but it gets you 100% of pulseaudio with 90% less problems!

Re:Linux audio

[Anonymous Coward]

What apps broke? OSS apps are broken, in that they hog the soundcard. They used to do that under pure OSS too.

Why wasn't the OSS implementation fixed instead of reinventing the wheel repeatedly? How are those new wheels working out?

Fact is we can run decade old audio software on Windows & Solaris, and never needed crap like ESD.

Re:Linux audio

[Anonymous Coward]

Oh my god. Have you ever really really tried to do anything semi-professional audio work? Your post just shows an utterly lack of knowledge of the recording process.

> "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.

Oh REALLY? I where do you process all that "signals", do you have a magic box for that? (I mean, I have one, it's called: MY COMPUTER)

Please sir, if you don't know ANYTHING about a topic just try to keep your stupidity to yourself and don't waste everybody's time with an useless opinion.

Re:Linux audio

[loufoque]

alsa can do this with dmix and softvol.

AFAIK, dmix and softvol do not allow to change the volume of any application stream while the applications are running: they can only define pseudo devices that redirect to another device, altering the volume.

That's quite less powerful.

Re:Linux audio

[Trogre]

Yes, this is true. I don't think any software allows you to adjust individual sources (or tracks even) for latency, i.e. tell it your MIDI device has 20mS latency and your direct WAV output has 0mS latency, and let it auto-correct everything. This would be useful.

A lot of DVD players do this to allow for TV latency. Hell, mplayer does it (for a/v sync). I don't see why high-end software wouldn't allow for this.

Re:Linux audio

[Torrance]

The article you're probably thinking of is State of Sound in Linux Not So Sorry After All.

Re:Linux audio

[Burz]

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.

Indeed. One of the main reasons I wrote my sig:

Re:Linux audio

[mrchaotica]

Do you have a better idea how this should be handled while being as flexible?

How about keeping PA and JACK but skipping the ALSA layer, then (especially since non-Linux systems apparently manage without it)?

Re:Linux audio

[mrchaotica]

I cannot enjoy listening to synthesized music. It sounds cheap.

That could be because sometimes it is cheap -- as in, rendered using a cheap, crappy synthesizer (such as an older computer sound card). A good stand-alone sound module (or software with a good set of sound fonts nowadays, I suppose) can sound indistinguishable from a real instrument, in my opinion.

Re:Linux audio

[Anonymous Coward]

aww you poor baby. why don't you just pray to teh jesus to smite those unholy "fake" instruments?

i'm sure electronica makes jesus cry too.

Re:Linux audio

[Per Wigren]

How about keeping PA and JACK but skipping the ALSA layer, then

But how should PA/JACK talk to the sound card? ALSA (not counting the userland plugin system) is pretty much an API and a collection of drivers.

(especially since non-Linux systems apparently manage without it)?

Because they use something else instead of ALSA, like OSS, Core Audio or Direct Sound.

Re:Linux audio

[CAIMLAS]

It's really not all that surprising, because it's a complex topic with multiple and different answers, depending on which devices we're talking about.

Is it an ALSA capable card? Oh, it works with OSS too? But OSS piggybacks on ALSA? What's pulseaudio do? So on and so forth. I've been using Linux for over a decade and have gotten all this 'sound' stuff working on my systems w/ esoteric/glitchy hardware a number of times; I've rebuilt countless kernels and used beta ALSA crap once. If someone such as myself is confused by the broach of the topic, then the common Linux geek, nevermind the common Linux user, has little chance.

Re:Linux audio

[jabjoe]

Of course not, but it can ensure it doesn't get interrupted until it's done. Which means it can get the work done faster than it would if interrupted. I'm thinking context switching. If it's done uninterrupted in kernel, that is less context switching then if it's done in user space.

Re:Linux audio

[jabjoe]

I'll ignore the insult. I think you misunderstand what I mean. I mean, if it's done in kernel space, there is less work being done, so it's faster. You context switch in, process and context switch out. Plus, during the "process" stage you can ensure the process isn't interrupted. This boils down to micro-kernel vs monolithic kernel argument. Using FUSE as my reference, I admit that userspace filesystems can be fast, but I'm unconvinced they wouldn't be faster in the kernel without the extra context switching. If you have some papers to point me to "enlighten" me by all means point me to them.

Re:Linux audio

[marsu_k]

Syncinc to vblank is trivial with (closed source, but unfortunately still the top performer) NVidia drivers, it's a simple checkbox in nvidia-settings. But as you mention UXA I gather you have an Intel chipset, and at the moment they kind of blow in Linux. Granted, I haven't tried the latest kernels/drivers with UXA, so perhaps the situation has improved. But you might want to try this, it removes tearing for me.

Re:Linux audio

[bluefoxlucid]

Possibly. I'm talking about using the lowest-end software on low-end systems to do things that probably got done on high-end low-latency systems with expensive (pirated?) software and external hardware synthesizers. Actually I could probably use samples of synthesizer output for most of it.

Re:Linux audio

[bluefoxlucid]

No, that's one audio source. I'm talking about when you have a guitar, vocals, a Korg, a MOOG, midi tracks, three MIDI synthesizers used to render those MIDI tracks, and tracker-style sampled instruments, all used to produce one fluid track. You've got 30 or so tracks to get lined up to create your output. The external hardware devices will all react with different latencies; the internal software effects and sample mixing will react much faster; etc.

Re:Linux audio

[bluefoxlucid]

You assume that 1) Context switching is the only overhead here (as I said, you will have to copy_from_user and copy_to_user()); and 2) that locking the whole system to prevent the process from being interrupted would be optimal (it's not; when you finish, you want more data, and the real-time reactivity of the system is impacted).

Linux's "Microkernel" implementation is a joke. Look to a modern OS like Minix3 for a serious microkernel implementation. Minix3 uses a message passing scheme that's self-validating (i.e. secure without having to check the messages for validity), zero-copy, and thus fast. Each of the servers (portions of the kernel) runs in the same VMA layout with different permissions, so there's no cache invalidation or TLB flushes during context switches between microkernel functions (the kernel OR the servers).

This effectively means there's slightly more processing overhead, but it's got no lower bound like with a solid context switch. Linux uses a similar method to context switch into the kernel; the upper area of memory is TLB invalidated and cache flushed when you return from a syscall, avoiding the major impact of a context switch. Intra-process thread switching is similarly handled, thus fast. Minix3 servers are similar to Linux kernel threads in that respect, if Linux kernel threads ran at user-level permissions.

Re:Linux audio

[Reservoir Penguin]

Well, as they say - Linux developers are not your personal army. Everyone works on what interests them academically or on what they are paid for by Redhat, IBM and Co.

Re:Linux audio

[yossarianuk]

Although I have dabbled with OSS4 in the past with success, Alsa is the way to go to have an easy life and working sound.

I run Archlinux (Alsa) and Ubuntu (Pulseaudio), All issues I have with sound (i.e quakelive) occur only with Ubuntu, there are always work a rounds/fixes, etc - due to pulseaudio. Arch linux everything generally just works... Just try quakelive on a non pulseaudio system - it just works ....

Installing the alsa-oss package usually ensures that ALL oldere games / apps work (as far as I have tried)

Re:Linux audio

[Tetsujin]

there is an equivalent of FUSE for character devices that can be used for proxying OSS sound through ALSA

That quote shows how much of a train wreck Linux audio is.

Well, agreed with the state of Linux audio in general - but this sentence (and, digging deeper, the OSSP information) says to me that they've just made a substantial improvement to the overall situation...

I mean, there's a basic issue at play: Alsa can provide software mixing for multiple audio clients, but if you've got some OSS-based applications still on your system (which is hard to avoid, really) these would normally go through the OSS emulation layer of Alsa - which, unfortunately, bypasses the software mixer and possibly (depending on your hardware) blocks other access to audio output until it's done...

There have been other methods for OSS emulation, pushing the data out to one sound system or another - I don't know all the details of how these worked (created FIFOs for /dev/dsp, etc., I guess?) or what went wrong with that approach - But providing kernel support that lets a userspace application provide the implementation for the actual OSS character device files means that a lot of the problems with OSS emulation should go away... And as a result one gets OSS emulation which should be a lot more reliable, and which plays nice with ALSA's audio stream mixing features, without a full sound daemon involved.

From the sound of it, OSSP also allows multiple access to its OSS emulation, distinguishing different instances by their process groups. I think this will be a great improvement.

Re:Linux audio

[walshy007]

Awesome video with a performance done live, she uses several softsynths on the mac pro, the red led button thing you see is a monome, a midi controller, using ableton she samples her own voice then proceeds to use it in a soft synth along with the other bits and pieces.. if the delay between midi button being pressed and it getting sent to the audio card is 20msec+ as you would indicate, she would have to delay the master out to take that into account, and it would look horrendously out of sync on TV.

You're usage completely different to this, but what we are doing is done all the time, by all sorts of performers, it's the normal setup now. And it does require low latency. Which was initially what started this.

Yes, I mentioned that there's soundfont crap in the hardware driver, i.e. instead of letting a coprocessor do the work with $MEGABYTES loaded to sound card and $BYTES sent to it, we use the CPU to render $MEGABYTES and transfer it over the PCI bus to the sound card. Just moving the latency around and inflating the bandwidth usage.

you still incur the latency from cpu to sound card no matter what, but with sound card soundfonts you are traversing it multiple times because the cpu still has to feed the count card instructions to do what it wants to do. It is a lot more efficient to only incur that penalty once, and with a tiny enough buffer (256 samples I think in the case of 4msec) being constantly fed. It is minimized.

You'll never get rid of it, but it is a great deal less than what you would have formerly had. Things in cpu/ram have far less latency working with eachother than they do working with something on the pci bus. Tens of thousands of cycles can pass before you can do a single thing with pci.

Yes, this is true. I don't think any software allows you to adjust individual sources (or tracks even) for latency, i.e. tell it your MIDI device has 20mS latency and your direct WAV output has 0mS latency, and let it auto-correct everything. This would be useful.

Your midi devices should be synchronized with the master clock, a 20msec lag to the sequencer is insanely high, again from button pressed to your ears, 11 or 12ms is acceptable, lower, about 6 or so is ideal.

what else do we have here, Apple's take on software synthesizer latency which also says 6msec or so is ideal, lower is better etc. Note that this is all about the sound card buffer latency, none of the other parts (soft synth, midi input) are taken into account, because they are almost nothing in comparison.

Not physically possible. In one setup you may have SWXG-1000 Yamaha MIDI synthesizer program running, which has its own latency response, typically 50mS or more (I've seen it non-functional at anything below 120mS for real-time playback on an idle 1GHz CPU). In another you may use an external rack-mounted MIDI synthesizer, which means you have PCI bus latency, out through the USB host controller latency, out through a USB-serial adapter at some end, programming a MIDI sequencer in real time, which then has to fast-calculate things and produce output. This isn't instant.

Well people are doing 'the impossible' every day for their typical setups. It isn't instant, but if you can get everything from one end to being output in under 10msec, you're set. Ask anyone using a midi keyboard hooked up to logic with soft synths, which is a very common setup these days.

You're saying the setup I have is impossible, as is that of easily 90% of the users of apple's logic software that heavily use midi with soft synths. Latency has a massive effect on how you play when it sounds 'off'

Re:Linux audio

[Anonymous Coward]

"Modern Technology" requires a specialized OS and specialized software to "almost" get it right, "sometimes."

It's called MacOS X with Core Audio or Windows with ASIO. Both proven to provide low latency and making ordinary computer hardware do marvelous things with Audio.

Going by your rant that its nigh impossible to do midi + audio + etc in realtime then by that same definition the following set of artists taken as example would not be able to make music if it wasn't for digital sequencing.

Trent likes Apple's Logic Software.
Daft Punk and Bjork on many occasions use an ethernet driven midi controller. Latency Much? See the JazzMutant Lemur
Aphex Twin, He's hooked up more then his fair share of weird shit and made it work.
Daedalus / Prefuse 73 / Eluvium / Venetian Snares / etc.

Without modern tech we would not have the sonic landscape we have today. Nor would many interesting live performances be possible.

If your Sequencing / DAW workstation is not capable of keeping everything in sync and under a preferred 11ms latency it simply means your rig is not up to the task of what your demanding from it.

So by default I call BS on your statement, as well as wanting a 0ms latency being rhetorical for even being mentioned.

Re:Linux audio

[Tetsujin]

Where do you think is the fastest place to process, kernel or userspace?

The CPU doesn't run magically faster when it is running kernel code...

Latency, rather than raw processing speed, is the primary concern for audio. In lieu of a proper real-time process manager, putting the code in the kernel would I expect be potentially rather helpful.

Re:Linux audio

[bcmm]

That isn't a scary diagram, it's just a very detailed one. Cairo being capable of writing PNGs doesn't make Xorg more complex.

Re:Linux audio

[hanger]

Ever heard of "If it works, don't touch it"? No one forces you to update your kernel with every minor release.

Re:Linux audio

[TheTyrannyOfForcedRe]

The open source radeon driver does immaculate, tear-free video with every player, no gl required. I've been running it on an R600 card for months.

Re:Linux audio

[Anonymous Coward]

... Windows 95 is superior to Linux in almost every respect. ... the [Linux] kernel for faster SMP with 64 CPU systems

I don't get you ... Windows 95 can't use 64 CPUs or 2+ GB RAM or any modern device -- and you can't fix it because there are no knobs to turn. With Linux, if you can't get your music to play and you don't have the know-how to fix it and you're too lazy to turn the right knob for your system implementation -- then get an iPod.

Re:Linux audio

[walshy007]

I suffer no latency problems with PA

That is likely because you don't do anything that requires low latency, even with high latency you won't be able to tell while watching youtube or movies if it's been done right.

Other tasks like live midi stuff tend to require low latency or it will sound extremely off.

PA and jack can coexist (and the developers of both have been working together for some time now to ensure this is so)

Yes, they have been trying to work together, but serious question have you ever tried this setup? It's not pretty, the pulse audio sink for jack has a myriad of problems, and most of the time it just plain doesn't work.

This may improve in future, but for now it is extremely hit or miss, with most of the time being miss.

Feel free to read up on things so you understand them before posting.

Better yet, try implementing them, I have.

Re:Linux audio

[kelnos]

Other tasks like live midi stuff tend to require low latency or it will sound extremely off.

... which is why you should be using jack for these sorts of things.

Yes, they have been trying to work together, but serious question have you ever tried this setup? It's not pretty, the pulse audio sink for jack has a myriad of problems, and most of the time it just plain doesn't work.

This may improve in future, but for now it is extremely hit or miss, with most of the time being miss.

I never said it worked perfectly, just that there's been a commitment made to support this setup. PA is a new technology, and the basic concept of sharing an ALSA device between two sound-server-like apps is completely new as well. These things just don't magically start working overnight.

Better yet, try implementing them, I have.

Have you filed bug reports and tried to help fix the issues, or are you just complaining uselessly?

Re:Linux audio

[JonSimons]

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.

I'd mod you up if I had points, because I agree so strongly.

Yep; working. Part of the definition of enterprise-quality software.

Re:Linux audio

[walshy007]

Have you filed bug reports and tried to help fix the issues, or are you just complaining uselessly?

The problems I had were known existing ones, so why submit an identical bug report when one already exists? (yes I actually checked their bug database for it before submitting)

While I could provide stack traces and debugging information, I have no doubt they already have this. Also before you say I should start fixing it myself, while I do occasionally help maintain OSS software, this is specialized enough and enough of a core service for me to know when to leave it to people whom sound coding is their specialty.

If it's a known issue with that level of severity and not already fixed, somebody with not a terribly good knowledge of the codebase would likely find it a gigantic waste of time trying. Even if I succeeded the cost (in time) to benefit simply isn't there.

As it stands everything I like except flash supports jack, but the kinds of programs I use aren't even dependent on QT/GTK so my usage is abnormal. I just tend to see pulseaudio as superfluous, the tasks it is useful for jack is better at, the only main advantage it has is very good support for oss/alsa/esd/arts backwards compatibility, which as direct backends are basically all heavily deprecated anyway.

IPv4 over Firewire?

[0100010001010011]

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.

Re:IPv4 over Firewire?

[FinchWorld]

It never took off? I've only ever used firewire for networking once, and that was for the sheer novelty of seeing if it could be done.

Re:IPv4 over Firewire?

[tecnico.hitos]

Other priorities, I think.

I have yet to see a Firewire device and only have seen a few PCs with Firewire ports.

Re:IPv4 over Firewire?

[DavidpFitz]

I have yet to see a Firewire device and only have seen a few PCs with Firewire ports.

You've never seen a MiniDV camera, then?

Re:IPv4 over Firewire?

[tecnico.hitos]

Actually, no.

Re:IPv4 over Firewire?

[uhmmmm]

I haven't looked at the official changelog or the code yet, but I'm just as confused as you about that item. Moreso perhaps, as I have used IPv4 over firewire with two linux machines before. That was probably 5 years ago or so.

Re:IPv4 over Firewire?

[muckracer]

Networking over USB would be awesome. Link 2 PC's with USB cable and voila! Hell, even being able to mount an internal drive that way on the other machine would be cool. Anything like that in the works (haven't checked)?

Re:IPv4 over Firewire?

[Anonymous Coward]

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.

Re:IPv4 over Firewire?

[Anonymous Coward]

What about using a CAT5 cable between two USB NICs?

Re:IPv4 over Firewire?

[Anonymous Coward]

I don't get you folks. What a weird router you have there playing network via firewire?
In fact, this stupid network over firewire driver came as default network interface messing up my ethernet connection!
And that was a few years a go.
Seriously. What's this craze about firewire? 1Gbit via ethernet is not enough??

Re:IPv4 over Firewire?

[Anonymous Coward]

USB is not a multi master bus like FireWire, you'd need special hardware between each of the computers usb ports in order to even begin to do any networking. By that point you might as well just go and get a crossover cable and a few NICs (assuming said computers have none).

Re:IPv4 over Firewire?

[tagno25]

Seriously. What's this craze about firewire? 1Gbit via ethernet is not enough??

Firewire networking came about before Gb network cards (in consumer equipment)

Re:IPv4 over Firewire?

[MMC Monster]

How the heck can you reliably pump video from a video camera to a PC? While USB3 has similar bandwidth, the overhead of the protocol, especially when there are other USB items in the chain, slow down the real throughput.

I know, . Anyone pull up a good comparison on google?

Re:IPv4 over Firewire?

[Lemming Mark]

How was the parent modded troll, it's completely valid!

It's a good idea. There have been networking over USB devices (by which I mean plugging both machines USB ports into the device, not "merely" a USB ethernet adaptor). The problem with doing this with USB, rather than Firewire is that USB has a really strong concept of "host" and "device". The cables are made to only plug into certain combinations of endpoints because, sadly, only certain combinations of endpoints can possibly work. You can't plug the host controller of one PC into another, since they're only expecting to talk to devices, not another controller. This is in contrast to Firewire, which is peer-to-peer and (in principle) anything could talk to anything over it.

The unfortunate consequence is that you don't just get to do networking over a nice, cheap cable as you do with Firewire. You actually need a little device box in between so that both hosts can believe they're talking to a peripheral, not another host. This approach, on its own, wouldn't let you plug in "remote" devices either so you'd have to set some other protocol up (plenty of existing options here) to talk to devices at the other end. You have to be a bit careful because most devices would barf horribly if there are multiple users - uncontrolled shared access to a disk device is a good way to lose all your data, for instance.

Although it's fun to do IP over Firewire, I'm not familiar with exactly how it's implemented. What intrigues me is the prospect of running increasingly sophisticated high-performance protocols over Firewire. As I understand it you can basically get remote DMA access to the "other end's" memory. This obviously has severe security implications but it could be quite nice in a mutually-trusting cluster. There are various protocols (e.g. used by Infiniband) for having communications over remote DMA. I wonder if anyone could put together an "infiniband lite" that just ran over Firewire. It'd be cool, though I don't know if it would be particularly useful ;-) (plus it would lack the user accessible networking Infiniband has)

Re:IPv4 over Firewire?

[Anonymous Coward]

this is ipv4 over the new firewire stack, the old stack had another implementation. but still, ip over firewire is rarely supported out of the box on linux, for example i don't think network manager deals with it.

Re:IPv4 over Firewire?

[Motormouz]

They've added IPv4 to the new firewire stack. You know, the one they put in the kernel some time ago in favor of the old one and caused some headaches to firewire users.

Re:IPv4 over Firewire?

[Anonymous Coward]

What about using a CAT5 cable between two USB NICs?

Now that's just crazy talk.

Re:IPv4 over Firewire?

[Anonymous Coward]

Firewire 3200 = 3.2Gbps.

Re:IPv4 over Firewire?

[fuzzyfuzzyfungus]

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.

Re:IPv4 over Firewire?

[0100010001010011]

You mean Target Mode, which Apple has had since the days of SCSI? However it does only work over Firewire.

You boot up your laptop and hold the "T" button. Mac Screen goes to a pretty screen saver of a Firewire logo. The machine it's attached to doesn't know any different and just sees an HFS+ formatted disk.

Target Disk Mode

Doing it 'live' I could see a problem because you'd have 2 machines fighting over trying to write to a disk, so you'd need some sort of 'host' server to control writing. More or less you could accomplish the same thing (not over USB) just exporting / to NFS.

Re:IPv4 over Firewire?

[Anonymous Coward]

iPods? Ever hear of them?

(and yes, they're on USB now, but for several generations they were all Firewire.)

Re:IPv4 over Firewire?

[TheGratefulNet]

or a video capture box. fw is still the best transport for realtime data like that.

funny anecdote: about 3 or 4 years ago, I was using my FW video box (canopus thing) when I had left it connected to the FW bus during a reboot. my asus mobo saw the FW device and - TRIED TO BOOT FROM IT! seriously. it would sit there and assume it was a storage class device and kept asking for its boot sector ;)

glad it wasn't a sony firewire box, though. it might have *actually* booted (and rooted) my system.

Re:IPv4 over Firewire?

[Abreu]

Thanks for the info

Re:IPv4 over Firewire?

[Hurricane78]

[...] only certain combinations of endpoints can possibly work. You can't plug the host controller of one PC into another, since they're only expecting to talk to devices, not another controller.

Not so with Linux. You can enable the "USB gadget" driver in the kernel. Now if you have a device connector in your system, it can act like any other device. That is how Linux on small devices connects to their hosts via USB. And actually, the way they communicate is plain and simple TCP/IP. :)

Re:IPv4 over Firewire?

[Hurricane78]

Well, that's a simple one to answer, if you understand free software:

Nobody cared. And developers only program things that they actually care about. Why would they do shit they don't like for free?
If you cared about it, what stopped you from making them care, by giving them some money?
Because don't look a gift horse in the mouth. :)

Re:IPv4 over Firewire?

[Kjella]

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.

And in recent years, also the prosumer/HDV market. I was deciding on a HD camcorder in 2007 and was on the tipping point, but landed at tape because flash was expensive, hard to edit and the first AVCHD implementations not that great, HDD was better on price but still had AVCHD limitations. Now they're in the third-fourth generation encoding chips, editing software has caught up, flash prices has dropped a lot, I'd go with flash on any camera costing less than 2000$.these days. And if not that, then HDD not tape.

Re:IPv4 over Firewire?

[Anonymous Coward]

Firewire was the USB competitor. It in many ways is better.

However we have a decent point to point system with ethernet. You can even connect two computers 'with just a cheap cable'.

http://learn-networking.com/network-design/the-difference-between-straight-through-crossover-and-rollover-cables/comment-page-1

USB was more of a replacement for PS2, RS232, and the centronics port. Firewire tried for the same thing but they wanted daisy chaining built in. Which is a good goal. But at that point why not just use ethernet? With the advent of 'thumb drives' usb won out with a cute driver hack. And the fact Intel built it in for cheap for every mb manufacture with its chipset. Trying to use firewire as a routing protocol and for what ethernet does well is just a interesting hack. But in the end not useful. If you are just looking for the speed boost that firewire entails then use a better ethernet.

Re:IPv4 over Firewire?

[Lemming Mark]

Yes, that's true, I should have mentioned that. But you still can't plug a normal host controller into another, regardless of the software stack you're running. You need special hardware that most PCs won't have that implements the device end of the channel. I think that it's something of a shame that PCs don't include this hardware but I imagine it wouldn't be that useful, given they all include ethernet ports these days.

Re:IPv4 over Firewire?

[BrokenHalo]

I have yet to see a Firewire device and only have seen a few PCs with Firewire ports.

A few years ago when I had my first iPod, I used to get random disconnects and overruns over the USB2 interface when hooked up to my Linux box. I bought an Audigy 2 ZS soundcard which included a convenient firewire port, and I was able to hook it up with no problems.

Now I have a machine with plenty of firewire ports and they never get used. I guess Firewire will still be useful for people with oldish camcorders or external HDDs, but apart from that I suspect it's gone the way of Betamax.

Re:IPv4 over Firewire?

[Anonymous Coward]

The design of USB (Specifically, the strict host-device idea) makes that utterly impossible without some extra hardware (Like this gadget) between the two systems.

Re:IPv4 over Firewire?

[drinkypoo]

Firewire tried for the same thing but they wanted daisy chaining built in. Which is a good goal. But at that point why not just use ethernet?

A basic firewire controller with pass-through is cheaper than a 2-port 1000baseTX switch and four times faster than using 100baseTX. Firewire can provide guaranteed I/O, ethernet cannot (at least not on its own.) Firewire is considerably simpler than ethernet plus another protocol. An acceptable firewire card can be had for about ten bucks with three ports. An acceptable 100Mbps ethernet card is only five bucks, but only has one port, and is much slower as well.

I could go on, but there are numerous reasons why firewire is superior to ethernet for use on a desktop or similar. Once you have to start going between rooms, or connecting one device to many systems, you can start thinking about other options.

Re:IPv4 over Firewire?

[Lemming Mark]

Argh, how was your comment modded troll? What is up with the mods today? It's a fair point - Firewire's niche is in professional kit like MiniDV cameras. Most people aren't using professional video kit, so these days it's quite likely you just won't see Firewire devices unless it's in your area of work. It's not like the original days of the iPod, where Firewire was required.

Re:IPv4 over Firewire?

[RiotingPacifist]

Biggest problem with this is there are no male-male USB wires, and once you need a specialist wire to connect to PCs then you might aswell just use a crossover cable and hardware that's designed for the task. Now you could argue that you just use female -> male adaptors (like TVs), but: 1)until such adaptors are easy to get there is little point in writing the drivers
2)until such drivers are written there is little point in manufacturing the hardware (goto 1)

Re:IPv4 over Firewire?

[RiotingPacifist]

you where obviously running a preemtive kernel, the thiotimoline drivers will be developed for 2.6.40

Re:IPv4 over Firewire?

[coolsnowmen]

I used to pull video from my cable box using a firewire port (I don't have cable anymore).
My first IPOD
My parent's DVCamera.

Re:IPv4 over Firewire?

[amorsen]

A basic firewire controller with pass-through is cheaper than a 2-port 1000baseTX switch

In this day and age, what do you use a 2-port switch for? You don't know that plugging the cable directly between cards just works?

Re:IPv4 over Firewire?

[Anonymous Coward]

Other comments have mostly answered this. I will just add that back in '05 I got OS 10.3 training covering IP over FireWire failover. Can't tell if 10.0 had this back in 2001 but if XP had it, then Apple must have implemented it earlier. Or perhaps the service packs added it after the original release of XP...

Re:IPv4 over Firewire?

[drinkypoo]

In this day and age, what do you use a 2-port switch for? You don't know that plugging the cable directly between cards just works?

We're talking about daisy-chainable firewire devices. The question was: "Firewire tried for the same thing but they wanted daisy chaining built in. Which is a good goal. But at that point why not just use ethernet?" Ethernet-without-switch-daisy-chaining-FAIL

Please try to keep up next time.

Re:IPv4 over Firewire?

[ConceptJunkie]

A very long time before, too.

Re:IPv4 over Firewire?

[Anonymous Coward]

USB OTG standard addresses this problem. But nobody uses it on motherbards.

Re:IPv4 over Firewire?

[mrchaotica]

You know, a few years ago every digital camcorder had Firewire (coincidentally, they all also tended to use MiniDV because flash/HDD-based ones hadn't been invented yet). If new ones don't have it, it's only because they switched to USB2. But that doesn't mean Firewire is "professional," it just means it lost (unfortunately, IMHO).

Re:IPv4 over Firewire?

[dbIII]

Marked troll because the feature was in the old driver and now the new and improved driver has it too so is ready to take over. Some mods substitute troll for the missing "misleading, ignorant and jumping to conclusions" mod we don't have yet.

Re:IPv4 over Firewire?

[CAIMLAS]

Probably a combination of factors. Firewire has always been primarily a "high speed, lower CPU utilization USB" - mainly for audio and video transfer from video cameras and the like. The fact that it was mostly an Apple-only interface for some time (and it's an Apple brand name anyway) probably has something to do with it. Now,

Don't get me wrong: I like Firewire, particularly when you compare it to USB. But it's slower than GigE for networking, not terribly common, and slower than something like eSATA (again, much more common). Most consumer PCs don't have it; servers don't have it; hell, I don't think Apple even ships with firewire anymore. I know I've had to specifically look for it in the past (so I can talk to my dvcams). It's just not on the "to do" list, I suppose.

Re:IPv4 over Firewire?

[CAIMLAS]

Uh, you realize that most computers that have USB onboard are going to have onboard Ethernet with autosensing ports, right? IE, plug any ethernet cable in (CX or straight TP) and you should be good to go. Oh yeah: not only will throughput with a GigE card at either side be vastly superior than USB 2.0, you're not limited to USB cable length specs, and you don't have to run your transfers over a CPU-hungry bus, but you'll be able to bridge over effortlessly to wireless (or anything else).

USB and Firewire networking has always seemed silly to me. Using something like next-gen Firewire, or even the SATA bus, as a "host bus extension" interface, on the other hand, sounds awesome: you could very easily turn a handful of systems into a true NUMA cluster without much cost OR effort (provided software support for using SATA as a controllercontroller interface bus, at least).

Re:IPv4 over Firewire?

[Lemming Mark]

The post I was referring to was the "What about networking over USB?". The confused post about whether the Firewire networking was new was at least understandable - having two stacks is a bit of an odd situation! (one that hopefully can now be resolved)

Re:IPv4 over Firewire?

[Lemming Mark]

Hmmmm, fair point. I always thought of Firewire as an interface that got used mostly by video professionals but I guess it makes sense if it was in video cameras in general.

OTOH, I'd guess that these days dedicated video cameras are orders of magnitude less common for amateur videoing than point and shoot digital cameras, so I guess it's still plausible not to have come across one. I see portable video cameras occasionally in the hands of others but I've never had one myself, nor recently known anyone who owns one.

Re:IPv4 over Firewire?

[Lord Kano]

Funny thing is that Vista no longer uses 1394 adapters as network adapters.

LK

Re:IPv4 over Firewire?

[Anonymous Coward]

it's been around forever: http://www.linux-usb.org/usbnet/

More FUSE-like stuff

[miketheanimal]

OMG. It might become a micro-kernel!!!

Re:More FUSE-like stuff

[Lemming Mark]

And then Linus might pass Andy Tannenbaum's programming classes ;-) I like this stuff, they're combining some of the user / programmer benefits of a microkernel without a wholesale changeover. Everybody wins.

USB 3.0: better than Windows 7

[Anonymous Coward]

Windows 7 will ship without USB 3.0 support.

Re:USB 3.0: better than Windows 7

[Anonymous Coward]

You're assuming there won't be a patch out before USB 3.0 devices take off. The devices have to come with Windows support else they're useless.

Re:USB 3.0: better than Windows 7

[sammydee]

Sadly this lack of support probably just means that no USB3 devices or chipsets will actually be produced until the next version of windows comes out that DOES support it.

Re:USB 3.0: better than Windows 7

[weicco]

I'm envisioning somekind of pack... which contains some soft of repairements, updates and upgrades... like Service Pack! ;)

Re:USB 3.0: better than Windows 7

[gabebear]

USB3 is going to be an expensive upgrade. The only controller chip currently available are $15/chip http://en.wikipedia.org/wiki/Universal_Serial_Bus#Availability The thicker more expensive cables required to make USB3 work are also a problem. USB1.2->USB2.0 technically wanted you to have higher-quality cables, but you didn't really need to.

eSATA seems like a much better solution.

• You can combine USB2.0 with eSATA http://www.reghardware.co.uk/2008/10/03/review_laptop_dell_latitude_e6400/print.html
• We don't need SATA USB bridge chips for drives!
• SATA 6.0Gb has 576Mbytes/sec of bandwidth to USB3's 410Mbytes/sec of bandwidth.

I hope Apple starts putting eSATA/USB combined ports on their laptops soon.

Re:USB 3.0: better than Windows 7

[JohnFluxx]

> SATA 6.0Gb has 576Mbytes/sec of bandwidth to USB3's 410Mbytes/sec of bandwidth.

Are these numbers actually comparable, or are they just theoretical figures? It's happened before that the slightly "slower" spec actually performs faster in real life (was it some versions of fireware versus usb? I forget)

Re:USB 3.0: better than Windows 7

[gabebear]

After accounting for the 8b10b encoding and command overhead, SATA 3Gb has ~288Mbytes/sec of real-world data bandwidth possible. Intel's SATA SSDs sustain 280Mbytes/sec. SATA 6Gb is just a faster clocked SATA 3Gb. The USB3 410Mbytes/sec is purely theoretical and pulled from wikipedia.

The speeds that marketing uses are:

• SATA 6Gb = 6Gb/s = 768MB/s (600MB/sec after 8b10b encoding)
• USB3 = 4.8Gb/s = 614.4MB/s (491.5MB/sec after 8b10b encoding)

Both USB3 and SATA use 8b10b encoding, which means the max theoretical throughput can only be 80% of their transmission speed. USB3 likely has more overhead since it's made to be used with a wider range of devices.

Re:USB 3.0: better than Windows 7

[gabebear]

I think the disparity with firewire drives and USB drives mainly came out to the quality of the bridge chips used. Each generation of bridge chips keeps getting better.

I'd guess that 99% of the high-bandwidth use of USB is disk-drives. Going through a bridge chip to convert USB to SATA is always going to be slower than just using SATA.

4G is slated to be able to achieve 1Gb/sec, but I doubt that will be common anytime soon.

Re:USB 3.0: better than Windows 7

[amorsen]

It's quite difficult to get decent performance from USB2, because the design of the host controller is such that the CPU needs to be involved in the transfer. If the CPU doesn't respond fast enough (perhaps because you're trying to do actual work with the machine), performance suffers. The problem is less with quad-core CPU's, since you can just dedicate a core to USB when doing transfers.

Firewire and SATA controllers can handle transfers pretty much on their own. Supposedly USB3 can do the same.

Re:USB 3.0: better than Windows 7

[shutdown -p now]

eSATA is good, but it cannot supply power over the same cable. For many devices, this is very handy.

Re:USB 3.0: better than Windows 7

[petermgreen]

USB3 is going to be an expensive upgrade. The only controller chip currently available are $15/chip
They will come down and intel is also almost certain to integrate support into thier chipsets.

eSATA seems like a much better solution.
eSATA has a few issues

1: the designers didn't include any power pins so even the smallest devices have to be externally powered
2: while atapi over sata should support anything that scsi did noone seems to actually bother to make anything other than hard drives and optical drivers with sata interfaces
3: you can only have one layer of port multipliers, it's hard to find them with more than 5 ports,not all hosts support them and i've never seen them in a USB hub like box with eSATA ports on both sides.

So esata will probablly continue to have a niche for high speed external hard drives but I don't see it expanding beyond that.

Re:USB 3.0: better than Windows 7

[gabebear]

USB3/xHCI is adding the capability for USB controllers to do DMA transfers, which will help offload the CPU on bulk-transfers.

I'm guessing USB3 bulk-transfers are still scheduled after every other request is satisfied. USB is designed to be a very low-latency bus for keyboards/mice and bulk-transfers will suffer if they are done when another device is chatting away on the same bus. It will be interesting to see what the real-world performance of USB3 bulk-transfers will be.

Re:USB 3.0: better than Windows 7

[gabebear]

High speed external disk access is the only thing that USB2 is really missing. I'm sure we'll move past USB2 in the next few years, but I'm not sure the future is USB3. Since you can combine USB and eSATA in the same port, you can get the utility of USB2, along with the high speed of SATA, at a fraction of what USB3 will cost in the near-term.

The 900mA power bump in USB3 is just about perfect though. This is just enough to run pretty much any 2.5" hard disk or laptop cdrom.

Re:USB 3.0: better than Windows 7

[petermgreen]

I'm sure we'll move past USB2 in the next few years, but I'm not sure the future is USB3. ...... at a fraction of what USB3 will cost in the near-term.
This really depends on the action of intel, the reason USB ports became so common (before there were many devices to plug into them) was because intel included it free in the chipset. If intel do that again (and they probablly will) then USB3 will become just as cheap for motherboard manufacturers as the USB2+esata hack.

ESATA will probablly retain it's niche of connecting high speed external hard drives for a while but I don't see it expanding beyond that. Eventually other devices will need that speed too and I don't see what they would use other than USB3.

The 900mA power bump in USB3 is just about perfect though. This is just enough to run pretty much any 2.5" hard disk or laptop cdrom.
Agreed.

Re:i'd just like to

[Lord_Frederick]

Give it up already, Richard.

70% drivers!

[millwall]

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.

Re:70% drivers!

[Anonymous Coward]

You have it backwards, we want more drivers, otherwise we'll go back to the days of next to nothing working for any device you pick off the shelves. Kernels are boring, once you have file systems, memory managers, etc, there's little to get excited about, and even then, it's all under the hood. Devices are what real users use.

Re:70% drivers!

[von_rick]

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.

Re:70% drivers!

[tecnico.hitos]

Which will hardly work in a new Windows system.

Re:70% drivers!

[kestasjk]

Enhancements like what?

Re:70% drivers!

[Timothy Brownawell]

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.

I would assume that the people writing drivers and the people doing core stuff are not the same people, so there's no "pushed back". Ideally you'd have driver writers employed by all the various hardware manufacturers, while core stuff likely only interests a much smaller group of companies that live higher in the stack (probably just system and support vendors).

Re:70% drivers!

[jellomizer]

Well driver problems are the real problem with Linux. It always has been. When push come to shove comparing Linux with other OS's even the Linux Zealots admit that it is a driver problem. Most kernel features will not directly effect us like driver issues. Once Linux fixes its driver problems then it should focus on getting more features in... However in the mean time, the kernel should be improved on what the kernel is supposed to do Manage Hardware interface with software. And Drivers help with the hardware interfacing.

Re:70% drivers!

[MrMr]

Odds are Linux is the only system where it still works, like my old canoscan device: No Mac OS > 10.3 no windows > XP. But perfectly ok with the generic twain stuff...

Re:70% drivers!

[walshy007]

Not really, the driver people aren't really the same as those who would be researching new and exciting ways to do what we already do. For quite a long time now driver development has been the majority of what the linux kernel development is.

Of course, every now and then they make something new like mac80211, but all that really achieves is more efficient code re-use and testing, which is always good but is still just driver development.

All the simple things an operating system kernel has to do hasn't changed over the last ten or so years, just the hardware has. Operating system theory was pretty much perfected back in the 60's

Re:70% drivers!

[MrHanky]

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.

Re:70% drivers!

[Anonymous Coward]

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.

Re:70% drivers!

[MBGMorden]

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.

Re:70% drivers!

[Skatox]

Well that's something i love from this release, the fixed a lot of drivers problem that my laptop uses.

Re:70% drivers!

[schon]

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.

$ find /lib/modules/2.6.27.7-smp/kernel/drivers/ -type f|wc -l
1499

Looks like you're in luck!

Re:70% drivers!

[MBGMorden]

Great - now if I compile these lovely drivers will they work on my buddy's (or more importantly, a user's) system running kernel 2.6.1? 2.6.22? 2.6.31? 2.4.5?

Dividing the source and binary out into separate files doesn't make it modular. The infrastructure to move the binaries around needs to be in place so that a driver can be loaded with little regard as to kernel version.

Re:70% drivers!

[Kjella]

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.

Re:70% drivers!

[Anonymous Coward]

And yet those drivers are developed and distributed with the kernel project at large. Out of necessity, really, given the hostility of the kernel developers to external drivers, and the constantly changing interfaces.

Re:70% drivers!

[gnud]

That's a valid point of view, but it directly contradicts OPs argument for less focus on drivers and more on other enhancements.

Re:70% drivers!

[Timmmm]

I totally agree, but it seems the linux devs don't want to have to maintain a stable driver ABI. I think that's a pretty silly position to take; hopefully they'll change their minds at some point.

Re:70% drivers!

[mR.bRiGhTsId3]

The advantage of a stable api is that even though the drivers may be crappy blobs that get no support from the parent company I'm still convinced the parent company is more likely to fork over engineers for the driver in the first place. If a company (for whatever reason) is unwilling to merge a driver into the mainline, the would probably see a stable ABI as a chance to write a driver once and then not have to worry about maintaining it aside from bug fixes. With a moving target of an ABI, companies probably see maintaining a linux driver as a continue expenditure.

Re:70% drivers!

[Zebedeu]

Is that really true?

I read somewhere that one of the rules for working in the Linux kernel is that if your patch breaks code somewhere else, you have to go there and fix it before submitting (that's actually proper procedure in any project).

So I can imagine that one guy (or team) working on core stuff will sometimes impact the way drivers work, and will have to dive in that code to fix it.

Re:70% drivers!

[TheRaven64]

The first is about making the kernel into a big message-passing daemon, which it turns out has a performance penalty

More accurately, it has a performance penalty on uniprocessor systems. On SMP systems, using a system such as the one used by Xen with lockless ring buffers in shared memory, it provides a performance gain.

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?

A stable ABI is less important than a stable API (which Linux doesn't have either), which reduces the overhead of maintaining device drivers a lot and makes regressions much harder to introduce accidentally.

Re:70% drivers!

[gbjbaanb]

I think the point of a driver ABI is that people could write drivers entirely separately to the kernel, and they wouldn't need recompiling for each minor release. Just that would encourage moving the drivers out of the kernel to a separate repository. That would make it easier to manage as the number of them increases.

Windows does have a lot of crappy drivers, but they also have loads and loads of good ones. Enough good ones that a lot of people don't complain about them.

Besides, is it more important to have a buggy driver, or no driver at all? Remember that a buggy driver that has its source released can have its bugs fixed by others. You don't get that in the Windows world.
I guess a lot of manufacturers will release binary-only drivers, but even if they are buggy, that doesn't leave in any worse state than we are already - those manufacturers aren't releasing drivers for Linux in the first place.

I think a stable ABI would be a good thing, and would only inconvenience a kernel dev a small amount. In the past it made sense not to have the ABI as things changed too much, but Linux is a much more stable beast nowadays (or should be!) so a stable ABI, even if its only for major releases, would be a benefit to Linux. If the ABI needs changing, then the kernel can be released with a major point increase.

Re:70% drivers!

[PitaBred]

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.

Re:70% drivers!

[Hatta]

Why is your buddy still running 2.6.1?

Re:70% drivers!

[pembo13]

They are modular. The even call what they are placed in 'modules'.

Re:70% drivers!

[Anonymous Coward]

Nothing you said precludes a design that provides binary compatibility. Hauling out the strawman of Windows driver hell doesn't change that.

Re:70% drivers!

[JohnFluxx]

Ah so now you're arguing that they should freeze the interface, and prevent any more improvements.

Read http://www.mjmwired.net/kernel/Documentation/stable_api_nonsense.txt

Re:70% drivers!

[JohnFluxx]

Far more likely is that companies will behave exactly like they do in Windows - not bother updating their drivers for new versions. There is a lot of old hardware that simply doesn't work in Vista etc because there's no incentive for the company to fix the drivers.

Whereas if it's in the kernel, all the drivers can be fixed at the same time.

Re:70% drivers!

[dbIII]

Bah! Stupid kids following the line that was thrown out by the Judge in Microsoft vs Netscape. The OS is not a solitaire game or a web browser or even the bash shell or gnu's version of ls. The OS is the bit that gets between the hardware and the applications. The OS is the kernel. There are also a few libraries that people can argue over whether they are part of the OS or not, and there are applications like "init" that people will argue either way - but really the OS is the kernel and maybe a few other bits.

Re:70% drivers!

[MBGMorden]

Because he is. Everyone can't be expected to be running the same version of the kernel I'm not running 2.6.1, but I do believe that my home system is running 2.6.28. Tieing driver development to a specific kernel release is insane. Look at the hoops Nvidia has to jump through to get drivers out. On Windows I download a driver - it works. For the last 14 years we've basically had three groups of drivers - Windows 9x, Windows 2k/XP, and Windows Vista/7. Outside of those broad groupings a manufacturer could release a driver and have it work on most any computer. Linux drivers have to be recompiled for every kernel release. Very, very few manufacturers are willing to stay on that treadmill, and so we get stuck with reverse engineered open source drivers that fall short of what the manufacturers could usually write themselves (just compare the open source Nvidia drivers to the Nvidia provided ones).

Re:70% drivers!

[RiotingPacifist]

Generally there will be a big feature release every few kernels (i could give a number but its done by whatever linux feels like doing for a release), then there is a lame release that is mainly bug fixes, then a couple of half lame releases where the drivers get upgraded to make use of the big features until linux decides he likes some new feature and it starts all over again.

Re:70% drivers!

[coolsnowmen]

Try to start reading w/ PitaBred's first sentence and not having amnesia by the time you get to the end.

Re:70% drivers!

[coolsnowmen]

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.

Re:70% drivers!

[Angst Badger]

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's a mature kernel, what do you expect? Development of actual new features is largely driven by need, so there comes a point when there just isn't much demand for "new features and other [kinds of] enhancements". The lion's share of the kernel's remaining shortcomings is lack of hardware support, and not just for obscure hardware -- there are a great many commonly available and widely used devices for which Linux lacks support. At this point, the bulk of kernel development should be aimed at drivers, and we should be celebrating the fact that the kernel is otherwise mature enough that we can spend lots of time improving hardware support.

In any case, as many other posters have noted, most of the people working on drivers would not necessarily be working on some other part of the kernel.

Re:70% drivers!

[jellomizer]

Many Hardware vender will not make Linux drivers because of GPL restrictions (I am sorry not everyone likes or agrees with the GPL, there will never be a world where they will). Leaving OpenSource developers to make drivers for hardware... Now this isn't a company each developer has their own itch to scratch now most of the fixes are with drivers that means most of their itches are with drivers... DUH. So I would suspect a lot of people are having a lot of problems with drivers. If by the nature of open source if there is a problem they can fix it.

Secondly a lot of people especially people who is switching to Linux doesn't buy a PC to run linux. They have a PC and wants to put Linux on it. Then when you put linux on it you find a bunch of things fail that you were use to working rather seamlessly. As Well doing your homework upfront doesn't always work. Because old products get discontinued and new products come out without informing the buyer. Here is a real Old Example. I ran Linux back in 1996 and my Modem broke. (Lightning strike) I went to buy a new internal modem. I went to the store and got the modem that should work. The box had a picture of it. I saw all the DIP Switches and I knew an ISA modem where I just flip the Dip Switches for the COM port will just work in Linux... However when I got home opened the box. It was a completely different modem. No Dip Switches it expected to use Windows 95 Plug and play features, heck the shape of the card was not even what was on the box. I returned it and argued to not pay a repacking fee because of false advertising. I had to get an external modem from now on because I couldn't trust internal modems for compatibility with Linux. So they often upgrade their product without really letting people know. Perhaps adding a litter to the model number or something... but overall very misleading.

If you use that driver for that hardware you will see a bigger need to get it to work would be far more important then a 1/100 second improvement in memory management. Having things work is a bit more important then speeds that you will only notice if you benchmark them.

Re:70% drivers!

[amorsen]

It would also mean that drivers would be stuck on 32-bit x86. Great.

Re:70% drivers!

[amorsen]

That would make it easier to manage as the number of them increases.

One of the great advantages of Linux is that improvements can be implemented for lots of devices at once.

I guess a lot of manufacturers will release binary-only drivers, but even if they are buggy, that doesn't leave in any worse state than we are already - those manufacturers aren't releasing drivers for Linux in the first place.

It means people will look at the packaging, notice that it says Linux support, and then find out that it doesn't actually work, and will then blame Linux. Manufacturer-written drivers are fairly universally crap.

Re:70% drivers!

[Hatta]

Everyone can't be expected to be running the same version of the kernel

Why not? Upgrades are free.

Look at the hoops Nvidia has to jump through to get drivers out.

The only hoop they really need to jump through is opening their source.

Re:70% drivers!

[amorsen]

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.

Re:70% drivers!

[ultranova]

Why is your buddy still running 2.6.1?

I'm still running 2.6.24 because that's the newest that NVIDIA Legacy drivers for my Geforce 2 MX will support, which in turn is best my MVP7 motherboard will support (as in, start up with).

Not all of us have 4096 CPU rigs. Those of us who actually are on shoestring budget kinda suffer from the constant changes to the internal interfaces of the kernel.

Re:70% drivers!

[MBGMorden]

Why not? Upgrades are free.

A myriad of factors. Some people may not have access to enough bandwidth (or an internet connection at all) to download new kernel source. Other people still may choose to delay kernel changes on live systems due to approved configuration issues (ie, on my production servers I'm not going to be downloading and recompiling a new kernel every time one hits). All in all, the monetary cost of an upgrade is hardly the only thing preventing people from installing it.

The only hoop they really need to jump through is opening their source.

Which is not going to happen - ever - for any and every piece of code. Particularly hardware drivers. So long as you insist on a smug sense of moral superiority you'll have to live with dodgy drivers so hardwired into the kernel's codebase that no one but a select few dare even bother trying to modify or improve. OSS advocates need to accept that OSS is one option among many. The all or nothing approach is shortsighted to say the least.

The sooner we learn that making distributed binaries a reality instead of relying on the "Hey - we can just recompile it again for this specific configuration!", the better off Linux will be as a platform.

Re:70% drivers!

[dkf]

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.

On the other hand, having a stable ABI (well KernelBI) means that you're disconnecting the development of the drivers from the development of the kernel, making it far easier for non-kernel people (including hardware manufacturers) to develop and support drivers, and that generally improves support for hardware. Which benefits lots of people.

Note that having a stable KBI doesn't prevent evolution of the interface. You just need to have a (stable, versioned) mechanism for the driver to get access to a table of function pointers that implement a particular interface version, which it can grab at the point when the driver is loaded. There's a slight performance hit, but that could be avoided by using a more complex rewriting scheme (but I'd rather use well-known techniques than hacky rewriting if possible). Some care is needed on the part of kernel developers to ensure that they don't break particular KBIs by accident (this is analogous to the costs you refer to, but less crippling) and driver authors also need care, so that they don't go badly wrong and instead fail in a neatly controlled fashion if their favorite KBI isn't available.

It's not technically hard to do (and userland code has done this for years). But it does take someone to say "spending a little performance on this is a good tradeoff"; too often that's not an attitude heard in kernel circles.

Re:70% drivers!

[Anonymous Coward]

I hope you know that Linux kernel is exactly the same thing as Linux operating system? Linux is not a microkernel like Mach. It is the original way to build the operating system as monolithic structure.

Even on the Linux, there is differences between kernel API's and system calls (OS API's for system). The Linux has kernel API for drivers. But same time Linux has OS API for system (system call) part.

You can not talk about Linux as it would be microkernel-based OS, like Hurd or Minix. You need to understand the fact that Linux is complete monolithic operating system like FreeBSD and other BDS's are or SunOS.

http://www.gridbus.org/~raj/microkernel/chap2.pdf

Re:70% drivers!

[Anonymous Coward]

Linux is modular monolithic operating system. The modularity is on the binary level, but not on the architechture level as on server-client or layered OS's with microkernel. So even that drivers and other functions can be compiled as modules, they are possibility to unload and load to RAM when needed. But when they are loaded, they act like they would be compiled inside the OS. Differences are not.

Re:70% drivers!

[Anonymous Coward]

>234,533,458 times to date.
rainman, is that you - or are you on impossibility drive

Re:70% drivers!

[Wolfrider]

Don't talk crazy. There have been so many Major Changes to the kernel between 2.6.1 and now that it would make your head spin. Modules are not *designed* to be compatible between kernel versions - that's why they need to be recompiled ( and updated by manufacturers, if they're binary-only. )

Re:70% drivers!

[MBGMorden]

Modules are not *designed* to be compatible between kernel versions

Trust me, that they're not designed to be is nothing new to me. What I'm saying is that the *should be designed* (look! it's more official between asterisks :)) to be. The tons of changes to the kernel between 2.6.1 and now should be properly abstracted from anything that a binary driver needs to interface with.

Re:70% drivers!

[jellomizer]

Linux driver support is more complete than at least that of Windows Vista.
Thats setting the bar high.

Excellent we are slightly more successful then Microsoft worst product in the same sector.

Re:70% drivers!

[coolsnowmen]

I understand that not all hardware is supported, and I understand the problem of buying something that looks like it will work but it doesn't for whatever reason (like your reason). What I don't get is why this is linux's problem.

When someone buys a computer preinstalled with windows, they don't expect it to work with OSX, linux, and OS/2. If they do, they are naive. however, there needs to be a simply way to find out. What would be nice is an official linux kernel sticker that means "all major hardware on this computer works in linux." I would want to shop at a store that had any-sort-of accreditation process.

Of course, the chicken and egg problem still applies. Linux will have a hard time approaching the necessary %marketshare without this convenience to the users; and hardware manufactures will continue to dismiss linux until a certain %marketshare is reached.

Re:70% drivers!

[Anonymous Coward]

Which is not going to happen - ever - for any and every piece of code. Particularly hardware drivers. So long as you insist on a smug sense of moral superiority you'll have to live with dodgy drivers so hardwired into the kernel's codebase that no one but a select few dare even bother trying to modify or improve. OSS advocates need to accept that OSS is one option among many. The all or nothing approach is shortsighted to say the least.

Ha ha ha. You proprietards are pathetic. That entire paragraph doesn't even make sense so I'm not going to bother with a line by line rebuttal. I'll just type this really slowly so even your proprietard click and drool brain will get it.

We insist on open source drivers and make very few concessions for closed source drivers for several very good reason. Firstly, Linux runs on many platforms, not just your x86[-64] Windows and Mac world. When I have open source drivers for, for example, my USB modem, (which I do), I can plug it into my ARM netbook and it will Just Work. If I plug it into my power pc desktop machine, it will Just Work. Sun Sparc box? I won't belabor the point any more. If the drivers were closed, I would be at the mercy of the hardware vendor for what platform the card would work on. It would be x86. There might be a 64 bit driver if I'm really lucky.

Secondly, what happens when this stable kernel ABI gets so antiquated that it has to be upgraded. Kind of like what happened between win 9x and NT. What if the manufacturer of my favorite peripheral decides to deprecate that device and not release any new drivers? No such problem with open source drivers.

And thirdly, I like the speed of Linux kernel development and would prefer there be absolutely no impediments to it's breakneck pace. I like downloading a distro and all of my latest hardware purchases just work out of the box without doing the Windows-esque driver hunt. Open source drivers give me that. The ABI can move where it needs to and the drivers can just be recompiled. Closed source drivers? We'll get to it when we get to it.

Yes, FLOSS is one option among many. From the perspective of me and my hardware, it is the vastly superior option. You and your like-minded Wintard and Mactard sycophants can just suck it and get out of our way.

Re:70% drivers!

[chromatic]

... that generally improves support for hardware.

Compare the OpenSolaris kernel to the Linux kernel.

Re:70% drivers!

[Burz]

I suggest the EXT4 devs take time off permanently and save us from their folly.

Why a desktop layer like KDE should have to detect the filesystem type and run disk syncs(!) to avoid data corruption is beyond me. I could get better results running OS X on top of UFS.

The EXT4 devs are blaming KDE for something that has nothing to do with them, and the former are actually repeating errors from the early releases of Reiserfs v3. Astoundingly, they refuse to take responsibility and blame the F&%&$ desktop layer. Lesson: Your apps are simply not safe on EXT4 using typical desktop hardware.

Truly, the BSD world is looking better and better all the time.

Re:70% drivers!

[TheTurtlesMoves]

The thing about a stable api is that its not a stable api. Even in windows where its claimed to be stable. They just don't tell the vendors thats its changed and then a bunch of drivers stop working. Service packs have broken drivers for me under windows, so a stable api doesn't seem to provide anything.

Re:70% drivers!

[JohnFluxx]

If Linux ever gets a decent market share then companies will be pretty much forced to write linux drivers, whether they like it or not.

Re:70% drivers!

[JohnFluxx]

Er, that was fixed like several days after it was discussed.

Re:70% drivers!

[MrHanky]

That would make sense if the EXT4 vs KDE problems weren't resolved some time ago (2.6.29 or 2.6.30), with EXT4 going back to EXT3's expected behaviour instead of the merely "POSIX compliant". Oh, and that makes you utterly and entirely wrong.

Re:70% drivers!

[gbjbaanb]

is that better than people looking at the packaging, notice it says no linux support, and sticking with Windows?

User mode drivers are obviously the way forward then, with a 'Linux certification' before you can install them in the kernel. Or a crash dump when things go wrong that firmly puts the blame on the faulting driver (in big letters).

Re:70% drivers!

[amorsen]

is that better than people looking at the packaging, notice it says no linux support, and sticking with Windows?

Yes. Saves them from buying the wrong thing. An unhappy ex-user is worse than a user who doesn't know about Linux in the first place.

Or a crash dump when things go wrong that firmly puts the blame on the faulting driver (in big letters).

There are a million ways things can go wrong and not result in a nice dump like that. It's only lately that PC's have acquired rudimentary I/O isolation, and it isn't used much yet. Even with that in place, it would be tricky and possibly performance-limiting to enforce isolation for all devices.

Re:70% drivers!

[CAIMLAS]

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.

Linux has "something like 10% market share" if you include servers. Yet even support there is seemingly marginal from the vendors.

Here's an idea, though: maybe if the various driver frameworks would stabilize - ie, nothing more than bug fixes - we'd see some drivers getting written for them. I know that's a bit of a cop out, because a lot of drivers don't necessarily need a stable API or the like (ie something like a USB camera which wouldn't take that much work to modify the driver for in the event of the USB driver framework changing). But in all seriousness, we've got frameworks for everything changing, often. And usually they're fairly drastic changes.

In 2003, we had 2.6 come out which was a completely - completely! - different driver model, so pretty much everything had to be rewritten (or ported, depending on how badly it was written to begin with). Then we had the Firewire framework written. The PCMCIA framework has been written/is being rewritten for the last couple years (my CF/PCMCIA slots were out of commission on my Thinkpad X30 for over a year before the machine was replaced). The driver framework for X - whether in kernel or in Xorg - has changed a half dozen+ or so times all told in the last 5 years, and that's not even including "small" revisions in X that make something like a 3rd party touchscreen driver no longer work. And then, for 6 months, my USB multi-card reader no longer worked due to a kernel upgrade (which was needed due to a remote exploit, IIRC). Oops! Somehow, that got fucked until -another- "major" point release in the kernel to get -properly- regressed.

I don't know how many times I've come across a driver that works on a version of the kernel or X 6 months or so ago, only to find that it doesn't work on any distros or kernels in the last couple months due to a weird regression in the kernel that the fucking devs decided to not acknowledge or tag as important because "it would get fixed downstream by the distros" or some such rot. Seemingly, this kind of thing has increased in regularity with the 2.6 model.

Re:70% drivers!

[coolsnowmen]

Your complaints about driver stabilization over time are valid IMHO. I think it would be smart if they agreed to not change the ABI for say 2 years at a time. Or rather, keep the legacy interface around for that long.

Linux has "something like 10% market share" if you include servers. Yet even support there is seemingly marginal from the vendors.

As far as market share is concerned. I'ld like to see a source. Everywhere I read puts linux ~2%.
http://marketshare.hitslink.com/operating-system-market-share.aspx?qprid=8
http://news.cnet.com/8301-13505_3-9910263-16.html
http://www.itwire.com/content/view/25361/1141/

Re:70% drivers!

[Burz]

And WHO fixed it??

Re:i'd just like to

[tecnico.hitos]

There really is a Linux, and these people are using it, but it is just a part of the system they use. Linux is the kernel: the program in the system that allocates the machine's resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system.

If the body is GNU, but the brain is Linux, what is the identity of the creature?

Re:i'd just like to

[Timothy Brownawell]

There really is a Linux, and these people are using it, but it is just a part of the system they use.

And that part is exactly what is being discussed here.

Linux is normally used in combination with the GNU operating system: the whole system is basically GNU with Linux added, or GNU/Linux. All the so-called "Linux" distributions are really distributions of GNU/Linux.

Or more properly, KDE/Xorg/GNU/Linux.

Re:i'd just like to

[Anonymous Coward]

Yeah, we all know that (Richard?), but "GNU/Linux" is cumbersome and dorky. I'd find another pet peeve--you won't find contemporary usage beating a path to your pedantic door.

Heck, when I mention Linux to my mainstream friends, a blank look is all I generally get, anyway. Why make life more difficult?

Horray!

[Anonymous Coward]

I've been waiting for this land-mark release since v2.6.30!!!

TTY?

[Anonymous Coward]

How about the TTY "hacks", did those make it to this release?

Re:i'd just like to

[Anonymous Coward]

Or more properly, KDE/Xorg/GNU/Linux.

Or more properly, (KDE||Gnome||XFCE||etc.)/[conky]/Xorg/Linux/GNU.

Yo dawg

[Lemming Mark]

We heard you like your audio to work, so we put a sound API in your sound API, so you can have silence whilst you listen!

Re:Yo dawg

[Lemming Mark]

FWIW, I don't actually think Linux audio is as bad as my comment may have implied. But, like many of us, I've experience "teething troubles" of several different sound technologies, most recently PulseAudio. It seemed like too good an opportunity to miss. ;-)

Re:i'd just like to

[C0vardeAn0nim0]

dumbass... TFA is _specifficaly_ refering to the kernel. if people want to use "linux kernel" to refer to linus' piece of code they're free to do so, just like some people call MS's operating system "microsoft windows", so just shut the fuck up.

Re:i'd just like to

[Anonymous Coward]

Linux is normally used in combination with the GNU operating system: the whole system is basically GNU with Linux added, or GNU/Linux. All the so-called "Linux" distributions are really distributions of GNU/Linux.

Or more properly, KDE/Xorg/GNU/Linux.

Okey, so it works that way... Just to see if got this right: I'm now using IE/Windows/VMWare/KDE/Xorg/GNU/Linux system. Later on, I plan on using Eclipse/Gnome/Xorg/GNU/Linux system. And so on...

troll

[Anonymous Coward]

Last I checked, drivers were a good thing, and people working on things that you don't care about doesn't hurt you (contrary to commonly held republican beliefs.)

enhancements are being neglected

[viralMeme]

"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"

I though the main bugaboo was the lack of hardware support in Linux. What other features and enhancements are being neglected?

Using CUSE for sound devices is The Right Way

[Lemming Mark]

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.

Re:Using CUSE for sound devices is The Right Way

[raddan]

So... from what I gather from your post, you can't just graft an OSS API on top of ALSA (or PulseAudio for that matter) because ALSA and PulseAudio run in userspace? Why are we putting sound daemons in userspace anyway?

Re:Using CUSE for sound devices is The Right Way

[pak9rabid]

Why are we putting sound daemons in userspace anyway?

Don't daemons by definition run in userspace?

Re:Using CUSE for sound devices is The Right Way

[Smork]

Take a look at http://fort2.xdas.com/~kor/oss2jack/ and the timestamps on that page.. This is a very bad case of deja vu, the 'fusd' framework is currently unmaintained (cusd is probably nicer..) but it's been around for a couple of years already. And guess what, the author of the above page wrote a userspace OSS device that couples to JACK. This stuff already exists for years!

Re:Using CUSE for sound devices is The Right Way

[Carewolf]

we need to wait for the sound daemons like PulseAudio to catch up

No, we need sound daemons like aRts, ESD and PulseAudio to lay down and DIE!

Re:Using CUSE for sound devices is The Right Way

[Anonymous Coward]

The end result should be that sound Just Works, even for awkward proprietary apps.

Not really, because as you have mentioned before:

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 [...]

meaning that latencies would be high.

For sound, even 50ms latency is too much. It might work in synthetic tests, but it will not work in real life. Just look at PulseAudio or older ESD or aRtsd for examples of how it doesn't work - and never really worked.

Re:Using CUSE for sound devices is The Right Way

[pedestrian crossing]

A-fucking-men!

Re:Using CUSE for sound devices is The Right Way

[Lemming Mark]

Whoa, thanks for the link! I'd never heard of that stuff. I shame it wasn't mainlined already or we could have saved ourselves some pain. It always surprises me just how much cool stuff is out there for Linux that you don't see.

Re:Using CUSE for sound devices is The Right Way

[TheRaven64]

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).

Re:Using CUSE for sound devices is The Right Way

[Lemming Mark]

Actually, it probably depends on your point of view. "Daemon" usually refers to a userspace process but OTOH, try the following:

ps -A | grep k.*d

Aside from (potentially) some kde processes you'll probably see a load of kernel threads for various things, e.g. kjournald. I believe the d there stands for "daemon" and is being used merely in the sense of "a process or thread that runs in the background and Does Stuff"

Re:Using CUSE for sound devices is The Right Way

[Lemming Mark]

Agreed it's not ideal. Well, it should be more like Just Working as compared to the current situation, anyhow.

In the current situation, most people have a weirdass sound daemon of some flavour and a load of OSS legacy apps that won't talk to it, necessitating an ugly hack to trick them into talking to the daemon. Using CUSE shouldn't add latency if done right (you still have to context switch to the sound daemon, copy some data, do some stuff, then call down into ALSA) and ought to improve the user experience for those apps. Other apps already talk to the sound server directly.

Eliminating the sound server might be nice, though it probably depends who you ask - some are convinced that having it in userspace ought to work fine. My main objection to sound daemons hasn't been that they add latency it's that oftentimes they seem to just not work *at all* in some crucial way :-( When they're working properly the latency doesn't bother me so much, it's just that still feels like a rare situation (on some distros, anyhow).

Re:Using CUSE for sound devices is The Right Way

[Hurricane78]

From what I know about FUSE, I know that CUSE for sound will be completely useless!

This is, because FUSE is slow as hell. And there is no chance to make it faster.
Now add to this the problem, that sound needs a *way* faster reaction time and extremely small delays, and you got a recipe for disaster.

I don't think CUSE got a chance replacing OSS4 and realtime Jack on a realtime kernel.

Re:Using CUSE for sound devices is The Right Way

[Lemming Mark]

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.

Re:Using CUSE for sound devices is The Right Way

[Lemming Mark]

As a point of interest, Xen runs paravirtualised VMs at ring 1 on 32-bit x86. I think other VMMs may run guests (paravirtualised or not) in this way too. They can get away with doing this since virtualisation tends to be quite hardware-specific anyhow.

Re:Using CUSE for sound devices is The Right Way

[Lemming Mark]

Hmmm. It sounds like the current OSS proxy daemon does send stuff on to PulseAudio, which does mean extra overheads. But PulseAudio could support the emulation directly via a plugin or something, in principle, so hopefully if the latency is a problem then it'll be fixed. Hopefully ...

Re:Using CUSE for sound devices is The Right Way

[TheRaven64]

Yes, this is true. Xen also uses a very neat system of lockless ring buffers for communicating between PV guests[1]. These use atomic increments on free-running producer and consumer counters so that two guests can communicate without going through the hypervisor. Something like this would make a userspace sound daemon more efficient, since it would remove the need for copying in and out of the kernel to move data between the app and daemon. It also means that, on an SMP system, the two can run concurrently.

You'd be surprised about how little of Xen actually is hardware specific, by the way. If you take a look in the IA64 and PowerPC trees, you'll see that the majority of the code is the same. Not many people use Xen on non-x86 platforms though.

One thing I forgot to mention as an advantage of doing it in userspace is that it's generally considered a bad idea to do anything with floating point in the kernel (it's an extra set of registers to save and load when calling to and from the kernel). This isn't a huge problem, because the fastest mixing algorithms use fixed-point.

[1] Obligatory plug for my book if you'd like to know more.

Re:Using CUSE for sound devices is The Right Way

[Anonymous Coward]

Or just use OSS4 which is compatible with all the old OSS except with new features (like software mixing).

Re:Using CUSE for sound devices is The Right Way

[raddan]

Thanks for the book link. I'll check it out.

BTW, since you are a systems guy, do any US schools stand out in your mind for their systems work? I am nearing the completion of my undergraduate CS degree. I'm limited to the US because my wife is a doctor here, and understandably does not want to leave the country. Sorry, it looks like you're not in the US, but I'm asking anyone I think might have some good insights because many CS departments seem to regard systems as passe (especially my current department-- they have a real thing for security-- blech!). I think this attitude is odd because this seems to be to be a very exciting time for systems work, especially OS and networks.

Re:Using CUSE for sound devices is The Right Way

[TheRaven64]

The best undergraduate operating systems course that I know of is at CMU, and they've got a lot of interesting systems-related projects ongoing. MIT is obvious. If you're interested in large-scale systems then Utah also has a good group, and their close collaboration with the visualization guys there gives some good sample workloads to play with (I spent a few months there during my PhD - it's a really nice place to be if you like skiing and beer). You may also want to talk to Intel, HP, or Sun Research. They are all funding research into scheduling at the moment (especially in relation to power management or heterogeneous multiprocessor systems), so if that area interests you then you might be able to get an internship and funding for the rest of the time from one of these companies, wherever you end up.

Re:Using CUSE for sound devices is The Right Way

[dylan_-]

This is, because FUSE is slow as hell. And there is no chance to make it faster.

Is it really? I'd always heard it was pretty fast, and a quick google throws up links like this. Do you have a link showing its poor performance?

Yay!

[British]

Improved acronym support!
Numbers higher than the last version!
greater infusion processor link array warp drive systems!

Re:Yay!

[aaaantoine]

Those warp drive systems make all the difference.

Support for what?

[saleenS281]

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?

Re:Support for what?

[rastilin]

Wait, so I'm supposed to be upset that Microsoft didn't ship experimental drivers for an unratified standard in their new OS?

What's really telling is that the previous comment got modded +4 Informative without anyone noticing this at all.

Re:Support for what?

[jbeaupre]

Don't be upset with MS, be happy for Linux. In fact, with support built in, Linux will frequently be used to develop and test the hardware. So some of the early USB 3 products will be de facto optimized to run with Linux.

Re:Support for what?

[PitaBred]

Drivers can be updated. The standard is almost there. There are a number of things that will NOT change with it. The problem is that USB has always been just "tacked on" to Windows. It's never been really well supported.

Re:Support for what?

[tehcyder]

Wait, so I'm supposed to be upset that Microsoft didn't ship experimental drivers for an unratified standard in their new OS?

Yes, you are. This is slashdot.

Re:Support for what?

[tokul]

Wait, so I'm supposed to be upset that Microsoft didn't ship experimental drivers for an unratified standard in their new OS?

No. But you should be upset when they ship experimental drivers that bluescreen their own OS after one click in web camera options.

Re:Support for what?

[Hurricane78]

Uuum... those controllers are standardized! That way you can have a generic driver.

Just as there are UHCI, OHCI and EHCI controllers, there is one for USB 3.0. I think that's the point.

How else would USB 3.0 support be implemented in Linux right now?

Re:Support for what?

[Anonymous Coward]

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

Intel release specs to developers. Just because lowly consumers like yourself can't get access to the modern devices, it hardly means box designers aren't already bashing away on them. Linux has Intel chipset support before any other OS generally, simply because Intel let the devs at the docs and have internal people contributing. Getting their code into the kernel now means they hit the ground running. Why do you think linux kernel supports chipsets that have only been on the market a few days, even if the kernel could be months old?

People like you are probably the first to cry when you buy a new box but your OS doesn't support it. Try thinking for once.

Re:Support for what?

[shutdown -p now]

The problem is that USB has always been just "tacked on" to Windows. It's never been really well supported.

Must be why I've yet to see a USB device not supported in Windows, but working fine in Linux.

(Oh, I'm sure you can find some obscure piece of hardware that does that. But on the whole, the picture is fairly clear.)

Re:Support for what?

[Anonymous Coward]

It's not a matter of whether the hardware manufacturer has provided drivers or not, that's not really the GP's point, I don't think. The issue is how smooth a given piece of hardware works on Linux versus Windows given quality drivers on both ends.

For example, I plug a device into a port on a Windows computer, unplug it, then plug it into a different port a day later and I get the "detecting new device" or whatever it is little yellow balloon in the tray says. I don't remember the exact wording. I mean, WTF? It's the same device I attached yesterday. While on Linux, you attach a new device, it tends to initialize faster (in my experience), and you can remove and reattach it all day long and it just works, essentially immediately every time.

File transfer to and from USB hard drives tends to be faster on Linux, again in my experience.

A great side effect of the open source nature of Linux is, when a driver makes it into the kernel, that hardware will always work. With Windows, if a manufacturer decides not to support the latest version of NT, you are shit out of luck. How many scanners work with one version but not the next? Guess what, want to use the latest and greatest? Go buy a new scanner. Not a problem in Linux. I have a USB cellular modem. A USB720 that I got from Verizon several years ago when I was still a Windows user. The experience of using the provided software to get online was just painful. It took at least 15 to 30 seconds to get going, the software would drop the connection when it felt like it, so on and so forth. Linux? Just works. No software, nothing. Perfectly integrated in the network manager applet. I click connect and inside of 5 seconds, I'm online. And the connection doesn't get turned off until I decide it does. It just works. The bottom line is, when there are quality drivers for a piece of hardware, the Linux experience is faster, smoother and just plain better.

Re:Support for what?

[Wolfrider]

Drivers can be updated. The standard is almost there. There are a number of things that will NOT change with it. The problem is that USB has always been just "tacked on" to Windows. It's never been really well supported.

--Maybe in Win98 days, but what's wrong with the USB support in XP and later?

Re:Support for what?

[PitaBred]

Plug your thumb drive into a different USB port and tell me nothing's wrong.

Re:Support for what?

[springbox]

That's how it behaves with all hardware, though

Re:Support for what?

[CAIMLAS]

Technically, yes, but in practice, not really. It usually works, but not always.

I've found the biggest offenders are wireless cards, at least where it matters. You've got to get it in the same port, consistently. With Linux, this is typically not a problem because the system doesn't keep a "log" of past devices plugged in: you get a new wifi adapter plugged in, it gets the next available device name. "Next available" in this case, means one which is not currently recognized and in use by the system. Then wireless networks are kept independently, and are not associated with a specific device.

With Windows, on the other hand, you can often swap a wifi device back and forth between ports/hubs when (not if) the wifi device inexplicably "dies temporarily". Actually, you usually have to do it, because a reboot won't 'reset' things properly. It's a real pain in the ass.

Part of this is due to the USB spec allowing for a vendor to not properly ID their device - as I understand it. But it's also how Windows treats USB.

Re:Support for what?

[Man Eating Duck]

Must be why I've yet to see a USB device not supported in Windows, but working fine in Linux.

Depends on what you mean by "supported in windows". Here are some obscure pieces of hardware for you:

I use a Logitech UltraX Media keyboard, it needed a special driver for the multimedia keys (play/pause, volume, and so on). When Logitech replaced their software with a newer version that refused to even let you choose this keyboard several keys lost functionality and some visual effects disappeared. In Ubuntu it interacts perfectly with everything by default, every button works as expected and gives visual feedback.

One time when I connected my Nokia to my Linux desktop via USB I chose the wrong option on the phone, PC suite instead of mass storage. I was slightly surprised when Linux told me that "You have plugged in a device with internet support, would you like to use it?". I was a lot more surprised when I yanked the ethernet cable, clicked yes, and was connected within five seconds. Why? I _never_ got it to supply my work laptop (Windows) with connectivity, even with Nokias fat, bloated software and "trying everything".

My girlfriend's Canon Powershot A300 was a bitch to get working in Windows, with special drivers, software and reboots. In Linux it showed up as mass storage and a twain device/camera upon insertion.

My Cardman 3021 smartcard reader was the same, a big hassle in Windows with two reboots (not possible to install the drivers with the reader plugged in - WTF? And no good warning. Download a 300 MB driver package, install it, shutdown, reboot, plug in the reader, reboot again because that was "necessary"). It was recognized by linux instantly, and a simple apt-get and a Firefox restart made it work with the Java applet I needed it for as well.

My Saitek P990 gamepad is a pain to use with WinXP. Special drivers, shifty calibration and button selection software, and lack of support for sticks, several buttons, or both, in various games. In Linux I can usually just plug it in, select it as a controller, and it will behave perfectly. And, what is it with Windows and required reboots? Come on, it's a fucking gamepad!

The list probably goes on, but I'm running out of devices. Sure, only one of those didn't work at all with Windows (and N95 is NOT an obscure device), but all of them were painless to use with Linux and not so in Windows. On the contrary I can't think of a single personal experience where Windows was better.

But on the whole, the picture is fairly clear.

Yes, I'd say that it is. Bringing up Windows as an example of good, general, native usb support shows a lack of experience with how it should be done. The fact that many devices don't work at all in Windows without the manufacturers adware might be a hint. I've supported Windows at work for nine years, so I'd say that my woes with devices in Windows is probably no PEBKAC error.

Speaking of usb, how is that portable, bootable Windows-on-an-usb-stick coming along? Sorry about that, couldn't resist :)

Remote device fun

[Lemming Mark]

How long until the APIs provided by CUSE are used to implement an arbitrary-character-devices-over-network protocol? That would be pretty cool and useful. Should be doable, from what I understand of how it works.

The description of the in-kernel changes on LWN's article on the subject (http://lwn.net/Articles/308445/) made it sound like the infrastructure could also be used for stuff like network filesystems whose /dev contains *remote* character devices (currently NFS device nodes are always serviced by local device drivers, so you can't use NFS to export devices). This might be especially useful for 9P, which is actually designed for device remoting since that's what Plan 9 did as a matter of course.

PPS

[anonieuweling]

LinuxPPS made it into the kernel: http://wiki.enneenne.com/index.php/LinuxPPS_support
The LinuxPPS project is an implementation of the Pulse Per Second (PPS) API for GNU/Linux version 2.6.

Re:i'd just like to

[Anonymous Coward]

I run Cygwin or, as I like to call it, GNU/Windows(tm).

Re:i'd just like to

[Kjella]

You fed the troll. You lose.

OSS is the unix way

[jabjoe]

Here we go again. I see the normal old OSS arguments that only apply to the old OSS Linux has.
If ALSA is so great, why did it never get copied out side of Linux?

Anyone else prefer having proper file interfaces for things like, Unix should do?
If I want to write sound I write to /dev/dsp1 if I want to read sound I read from /dev/dsp1.
If I want to write sound out to a second sound card, I write to /dev/dsp2. Nice simple device addressing system.
Now I use ASLA, because the Linux support is all geared that way, and it has always worked for me, but every time I have to deal with it directly, even addressing the right device, I recoil from it's ugly complexity.

ALSA can't kill OSS because Linux isn't the only open Unix platform and the others won't willingly take ALSA.
I have no doubt that ALSA can do things OSS can't, but how many users need those things? Don't mess up the whole design to nicely support a few fringe cases. I want to go back to Unix fundamentals. ALSA is like something from the Windows world, not the Unix one. Plan9 still looks like the future to me, and ALSA is going the the wrong way. ALSA depresses me. :-(

Re:i'd just like to

[Anonymous Coward]

GNU 1984 ->
Linux 1991 ->
KDE 1996 ->
Xorg 2004 ->

GNU started it all. It provides the philosophy, the tools and the license. Linux is just a nice milestone along the way.

An open source person calls it Linux, while a free software person calls it GNU/Linux.

is btrfs ready for regular desktop use ?

[C0vardeAn0nim0]

I'm now using EXT4 on my kubuntu laptop (a stop-gap waiting for a combination of latest ATI drivers + linux 2.6.31 + debian lenny to play along with each other).

EXT4 is wickedly fast, if compared with EXT3, and it looks stable. no data-loss or corruption, even with forced cold reboots (damn you to hell ATI !!! ). but ever since I got burned by reiserfs and the crappy fsck tools of the time, i'm weary of trying anything that doesn't begin with "EXT".

so, here's the question: how stable, data-loss proof is btrfs right now ? are the user space tools reliable if I need to check, recover, rebuild a FS ?

my particion layout is:

30 GB: / - OS and applications
5 GB: swap space
285 GB: /home - with all my personal files.

I can afford to lose /, it'll be a pain to reinstall everything, but i can survive that. but definetly can't afford losing /home/bento/Misc/XXX ... having the movies localy beats redtube hands down...

Re:is btrfs ready for regular desktop use ?

[anonieuweling]

http://btrfs.wiki.kernel.org/index.php/Main_Page has the info, answers, etc

Re:is btrfs ready for regular desktop use ?

[Tweenk]

btrfs is not ready yet. The chance to lose data due to an FS bug is small but still real. You wil be better off using reiserfs for /home and btrfs for root.

Re:is btrfs ready for regular desktop use ?

[hyperion2010]

no, it is still under heavy development

OSS FTW

[pedestrian crossing]

I feel your pain.

The only thing that has worked reliably over the years (and at the moment) has been OSS. ALSA kind of worked for a while, but since the latest Amarok upgrade, the only thing that works is OSS.

From my POV, Linux audio has gotten worse, not better. The audio quality itself is fine, but a couple of times a year the Next Big Thing in Linux audio comes along and fucks up my audio.

Then I have to waste hours fucking around trying to figure out the magic combination of either mixer settings or order of starting applications, which works once I figure it out only to get broken again some months down the line.

Yes, I am ranting, I had to do this very thing yesterday to be able to get usable audio out of Xine and Amarok.

I am hardcore for Linux, but the audio system is in a perpetual alpha-quality state and never gets better.

Fuck.

Re:OSS FTW

[Anonymous Coward]

Fuck.

Amen.

Re:OSS FTW

[CAIMLAS]

I agree - Linux audio has gotten much worse, as a whole. Sure, back in '98, there were only a handful of cards supported. But it worked.

For the longest time (oh, 6 years or so) I used OSS with ESD. That worked splendidly for me and never had a problem; it was also (for the day) trivial to set up. Then Alsa came along and I had some initial problems, but nothing too substantial (a little crashing when multiple streams were playing, or some such thing). Then Pulse came along... what a clusterfuck. I can't play an MP3 and surf even a single slashdot instance with that crap without the audio skipping and jittering. And forget about window manager audio hints lagging, or causing the other stream to jitter. Pulse is worse than the audio implementation in Win95.

It's too bad they couldn't have changed the underpinnings while simply keeping the frontend, or something. If Alsa wasn't working fine for me right now as a "standalone" with a little creativity (flash crap doesn't work well if anything else is using alsa - I think flash is using OSS, but I'm uncertain), I'd be using ESD still.

Re:Than don't expect an interesting hardware

[Anonymous Coward]

soon.

Re:i'd just like to

[DrXym]

To stretch the analogy... the body of a Linux operating system is composed of many, many different parts. It's like some demented taxidermist has stitched together lots of animal bits to make something either beautiful or horrific depending on your point of view. GNU software may comprise a lot of it, but there is plenty of other code which has nothing to do with GNU and arguably makes the OS something people find useful for something. The whole "call it GNU/Linux" movement is just silly and frankly smacks of some kind of deep seated resentment that Linux succeeded where Hurd didn't.

Re:i'd just like to

[Timothy Brownawell]

No... Eclipse is an application rather than part of the OS/platform, and IE is either an application or part of Windows depending on when you ask. VMWare I think should probably only be included if you would otherwise include your CPU etc.

native xfi support

[hyperion2010]

Finally ALSA adds in kernel support for creative X-Fi after 4 years, fuck creative.

Does this mean....

[Anonymous Coward]

I'd love to check out the new Kernel. It's a shame I, and the collective wisdom of the Ubuntu forums, can't manage to get the most 'user friendly' Linux OS up and running on my desktop. /Sad //Anonymous cause mentioning problems with Linux turns my posts into flamebait.

Mod Parent Informative

[mpapet]

This is the most sensible post in this entire discussion.

USB Doesn't Work Like That

[mpapet]

Networking over USB would be awesome.

USB doesn't work like that. USB is a master->slave specification whereas firewire has mastermaster functionality. Networking is a mastermaster type of relationship.

With that out of the way, some manufacturer somewhere had a device between two USB connectors that did what you are describing. It is/was in the USB Gadgets section and I didn't have the patience to fiddle with it. http://www.linux-usb.org/gadget/

I Love new kernel day

[Murdoch5]

Got to love when you can update to the new kernel, it's like Santa is coming but for Linux nerds

Re:I Love new kernel day

[Anonymous Coward]

Every 2 months we get new release of Linux OS, so it is like Christmas! Nerds loves to hussle their new OS release. But normal users are more intrested when new release of distribution comes almost every 6 months....

They dont care what release of the Linux OS is running on their distribution. As long as hardware just works. They are intrested about software applications and especially the desktop environment upgrades because they can see those and understands them. OS information is just for geeks and nerds... Not for avarage Joe and Lisa.

Re:I Love new kernel day

[Murdoch5]

Perfectly said, now don't get me wrong I love a good Gnome version update to and all the nice GTK software that goes with it. But when you take apart the distro it all comes down to Coreutils and and a Kernel.

I know that I did a gross over simplification so before anyone comes and complains about that lol I already know.

NILFS

[XanC]

Any thoughts on NILFS? Similar situation?

Re:NILFS

[gbjbaanb]

Nilfs? Nerds I'd Like to .. erm ... oh dear.

What the hell is KMS?

[default luser]

You click the article link, and it's still gibberish. You go to Google and search, and it's STILL gibberish. what in the hell is KMS, and why the hell does anyone care?

Re:What the hell is KMS?

[immakiku]

Kernel Mode Setting. You could care if you have a radeon, I guess.

Re:What the hell is KMS?

[patrickthbold]

Intel cards too, I think.

Re:What the hell is KMS?

[edlinfan]

(Vast simplification coming up.) KMS makes changing between video modes much nicer, so no more annoying blinks and flickers when you switch from a tty to X (among other things.)

It is also hugely important for the 'nouveau' nvidia open-source driver, which has been waiting for KMS to go live for a long time now.

Re:What the hell is KMS?

[default luser]

Thank you very much. Nobody seems to want to spell-out acronyms these days, let-alone explain the significance of new changes. I understood from the name that it had something to do with the Radeon drivers, and I found additional references to KMS Intel updates in Google, but I had no idea what KMS WAS.

Re:What the hell is KMS?

[default luser]

There's an Nvidia open-source driver? Really?

Does it support 3D? In recent chipsets?

Your name is Richard too?

[Anonymous Coward]

Give it up already, Richard.

If I may interject a moment, What another richard is refering to as Gnu + Linux to be the same as GNU/Linux is a phallacy that he spreads to multiply the lies the Free Software movement asserts over Open Source Software. You see, I am the richard that speaks of GNU divided-by (/) Linux, whereas GNU is the Least Common Multiple of a complete kernel that can run/transfer to a well-built program without the antiquities of initd to SysV or further to a GNU environment, Richard.

Re:i'd just like to

[Jah-Wren Ryel]

GNU 1984 ->
Linux 1991 ->
KDE 1996 ->
Xorg 2004 ->

Xorg is the result of work that started in 1984 too -- no one would argue that GNU today is what it was back in 1984, so other parts of the system should get the same benefit of the doubt too.

Re:i'd just like to

[slack_prad]

A normal person calls it ubuntu and moves on with life. Sheeeeeeeeesh!!

What about security?

[Anonymous Coward]

Is this exploit fixed?.

http://www.youtube.com/watch?v=UdkpJ13e6Z0
http://www.youtube.com/watch?v=P7uyCMdAldM

Re:i'd just like to

[Anonymous Coward]

Linux is not an operating system unto itself, but rather another free component ...

Linux a free component? this is not RMS...

Is "The Unix Way" always right?

[Tetsujin]

If ALSA is so great, why did it never get copied out side of Linux?

Adoption of, and migration to a different approach for doing things is not only a technical problem but a cultural one as well. For that kind of change to occur you have to get past all the people who say "what we've already got is good enough." For this to occur at all quickly usually requires someone powerful backing the new technology - even then, the effort may or may not succeed.

Bear in mind my intention here is not to say "ALSA is perfect, and people outside Linux just haven't embraced it yet because they aren't used to it.", more like "the question of whether ALSA is technically good is less strongly tied to the question of whether it has caught on outside Linux than one might expect."

Anyone else prefer having proper file interfaces for things like, Unix should do?

If I want to write sound I write to /dev/dsp1 if I want to read sound I read from /dev/dsp1.

If I want to write sound out to a second sound card, I write to /dev/dsp2. Nice simple device addressing system.

How does one know which device is which?

I think a device like /dev/dsp makes a lot of sense as a way to access the default audio device. When dealing with multiple devices, and particularly cases where the creation and removal of devices may happen at any time (i.e. USB hotplug, for instance) then it pays to have a more complete interface for dealing with such cases, and for finding out what kind of hardware you're dealing with on each device. I feel like the filesystem isn't a great interface for discovering newly attached hardware, and the sequential numbering of additional /dev/dsp devices becomes less sensible in that kind of case.

Personally my perspective on "The Unix Way" is that it is generally a good thing, but I think in its present form (on Linux, anyway) it is not always well-suited to dealing with the issues at hand.

That said, I know woefully little about either API. I want to use this discussion as an opportunity to learn more - and learn what's right or not about both approaches. Generally my point of view has been that programs that use /dev/dsp should just be rewritten to use ALSA - but after reading more of the discussion, at this point it seems to me that /dev/dsp makes a lot of sense for programs that just want a simple, widely-supported interface to audio... And ALSA is perhaps better reserved for programs that need to deal with multiple devices intelligently. It sounds like this OSSP thing will result in significantly better support for /dev/dsp on Linux, though (when using ALSA drivers, I mean...) - so that's good news...

I am curious about the latency issues involved with the software mixers on OSS and ALSA... I've never noticed latency on the ALSA dmix, not that I can think of anyway - but it's possible I just haven't been paying enough attention. I am curious if the OSS4 audio stream mixing really is better...

Why PulseAudio, anyway?

[Tetsujin]

I have been wondering for a while now, why do we still have audio servers? If ALSA and OSS4 both have support for mixing multiple streams, what's the point? I have to wonder if this:

You don't need pulseaudio. It is just a GNOME audio daemon that is many times better than esd, but still crap.

might actually be pretty much the whole answer... Is it just an API insulation layer? Or network transparency that I might never use?

When I got my EEE, I tried PulseAudio and Jack - I couldn't really see any benefit (and I could see various drawbacks) so I just went back to straight ALSA...

Insane Coding's Insane Plan for Networked Audio

[Tetsujin]

The article you're probably thinking of is State of Sound in Linux Not So Sorry After All.

Good article, but I've got to point out one really bad piece of misinformation this damn fool made...

"If users need remote sound (and few do), one should just be easily able to map /dev/dsp over NFS, and output everything to OSS that way, achieving network transparency on the file level as UNIX was designed for (everything is a file), instead of all these non UNIX hacks in place today in regards to sound."

<sigh> OK, let's break this down. First, you can't export a character device over the network via NFS. Or rather, you can export the character device file - but if you then attempted to write to a remote machine's /dev/dsp this way, you'd instead wind up writing to the local sound card.

Second, a naive approach like that doesn't do anything to manage the timing issues inherent with audio over the network. In some cases you don't care about latency but you do care about having the sound play uninterrupted - for instance, a "shuffle" sound in a solitaire game. /dev/dsp accessed over a network filesystem wouldn't do that for you - it would play part of the file as soon as it got it, and then, if too much time passed before it received the rest of the sound, there'd be dead silence in there. And then, consider the case of a video player: if a packet or two is lost along the way it's not a big deal, but what you care about is that packets are played in the order that they're intended. You need to strike a balance between latency and packet loss. /dev/dsp over the network isn't going to do anything like this for you, as all the packets are likely to go via TCP.

It's true that most people probably don't need network-transparent audio anyway (I don't) - but suggesting shipping out /dev/dsp over NFS is just brain-dead...