Slashdot Mirror

If you don't believe ALSA is just too complicated, look at this "simple" example:

http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm_8c-example.html

I can hear people now saying "so what if it's complex, people can always write wrapper libraries to create simpler interfaces." ...but the problem is that that is exactly what's happened. There are far too many wrapper libraries for audio in Linux and they cause a lot of problems. So one has to ask, why should playing a simple bit of PCM data require hundreds of lines of code?

Take a look Asus' Xonar range. The reviews look good (don't take my word for it, DuckDuck/Google is your friend) and there is a spectrum of quality/price to pick from.

If you're going to lecture people about understanding what they're talking about, you'd better understand it, or you'll just make yourself look like a contentious idiot.

And on how many distros does sharing the sound card between different accounts (you know, that thing I was actually talking about) work by default?

Considering this is a default kernel setting and all distros are using a Linux kernel this figure would approach 100%.

No, it is not a "default kernel setting". It is not even a kernel setting.

Simply put, if your kernel has ALSA support it has dmix.

Uh, no. There is no in-kernel mixing in Linux. If you want in-kernel mixing, install FreeBSD. The Linux kernel's sound system is designed for a single process to open a sound device exclusively (unless there's hardware mixing). Dmix is a plugin for the user-space ALSA library that makes the first process to open the sound device create a shared memory segment that other processes will map into their address space. This shared space is then used to coordinate mixing. Don't believe me? I'll cite code. Notice it isn't kernel code. Also notice how it's located the "first instance". And the error message if it fails? "unable to create IPC shm instance". IPC = inter-process communication. shm = shared memory.

Don't like running a sound server? Then don't run dmix. It does the same thing as Pulseaudio, only without a single dedicated process for mixing. It gathers up sound output from every process through shared memory and has one process mix it all.

Dmix has no purpose other than to allow multiple sounds to be played simultaneously. Dmix does not care about whether they came from multiple accounts.

Yes it does. Or more accurately, the shared memory segment it uses does have access rights associated with it. If you don't believe me, then explain this. Maybe there are a few common distros that share the dmix key with everyone in the audio group. All I know is, Ubuntu didn't do it, and it's a bad idea for security and reliability to create backdoors around user isolation.

If you had decency you would be embarassed that you are entering into this discussion without knowing basic facts like that. You would also admit that you shouldn't be spouting information that's more than six years out-of-date, that this makes your opinions about ALSA invalid. That's if you cared about truth and weren't just trying to posture and hand-wave.

Your rant is a better description of you than me. Except that what you're saying about ALSA isn't merely outdated; it's just plain wrong and has never been right. My description of ALSA is accurate and current.

That's a terrible default behavior. If the other user's desktop and applications go away when you switch to your account, why should their sound stay? It's inconsistent. I don't want to hear a random ad suddenly at high volume because somebody else left a webpage open that cycles through ads and eventually plays one with sound. A person should be able to use sound without logging into other people's accounts and closing their programs first.

For a user to have access to play sound, you must first add them to the audio group. If a user only ever connects remotely through something like SSH, then obviously you wouldn't give them permissions to play sounds on your hardware.

Is this even an honest mistake at this point? Are you really that stupid? I was not talking about SSH. I did not even mention SSH. I'm talking about logging in as a second user on the physical

Most Intel HDA codecs just treat all jacks the same, the only difference is the settings. If you want to play around, grab HDA Analyzer and tweak things to your heart's consent. For example, on my laptop (3 jacks), I can output 5.1 audio, or output 4.0 plus get one mic, or 4.0 plus one input, or output stereo cloned through two jacks (great for listening with a friend), or even make all jacks inputs, route them to the three stereo ADCs, and capture 5.1 analog audio. In fact, as far as I can tell, the only "special" jack is the headphones jack, which appears to go through some sort of extra amp to boost it as an output (more than the codec chip is documented to do, though strangely it still works as an input; it might just be another case of Realtek failing at documentation). Other than that, each jack has "in" and "out" options, a headphone boost option (this is the standard one built-in to the codec), a set of mic preamp settings, and a mic vref setting.

In other words, you just need the right software to do whatever you want with your audio jacks these days. Crappy drivers (both on Linux and Windows) will usually severely limit you, compared to the capabilities of the hardware. At least under Linux, you can always use HDA Analyzer to poke the real hardware settings (on Windows, you're probably SOL).

Your point about Windows getting hardware support first isn't entirely true. Linux supports just about everything right about when it comes out (contrary to popular belief, this includes sound cards). Ubuntu does use old versions. Jaunty was released in May, 2009, slightly over 2 months after ALSA 1.0.19 was released. By the time Karmic came out, Ubuntu was still using 1.0.18 (by this point ALSA was at 1.0.21a). That's 4 versions behind on possibly the most important piece of software to keep up to date (because the main change in each release is new drivers and better support for new hardware). Karmic is currently on 1.0.20 (2 versions behind at release) and ALSA is at 1.0.22.1 (making Karmic 4 versions behind). If any of those numbers don't make sense to you, it's because ALSA has a very strange versioning scheme.

I gave up on Ubuntu a while ago for Arch. It just bothers me that there's no good choice as a beginner distro. Ubuntu and Debian define stability in a way that doesn't make sense for desktop users, and the rolling release distros tend to not be user friendly (at least, not computer-illiterate friendly). I really think if Ubuntu separated out "things that should be stable" and "things that should be new" and did releases that way, it would make a lot more sense. For example, any program that a Windows user would download from the internet and install (Firefox, Pidgin, OpenOffice, etc.) should always be up to date, while you can just apply security patches to an old kernel for years and no one will notice. And then they make it incredibly difficult to update if you need a newer version of something like ALSA..

Ardour is the only Free software DAW suitable for any serious work. It uses JACK, which is an excellent low-latency audio routing system, but actual audio playback on Linux depends on the ALSA backend, which varies in quality depending on your hardware. Check the Alsa SoundCard Matrix for details. Recent Linux kernels have reasonably low latency by default, but for very tight latency requirements you might need a custom kernel configuration or patches.

I just looked it up to make sure I wasn't missing something, and Debian splits alsa up strangely so it's hard to say exactly which package is which, but Debian's ALSA packages have versions from 1.0.15 (released Oct 2007) to 1.0.17 (released June 2008), and ALSA current is entirely 1.0.21 except for ALSA-OSS which hasn't been updated since 1.0.17. So, Debian has no ALSA packages less than two versions off, and the majority are around 7 versions off. Sources: Debian Stable Package List and AlsaProject Homepage.

PS: Ubuntu, being released much more frequently, has managed to update to ALSA 1.0.18 (released Oct 2008).

You'll find that many pro-audio products are supported by ALSA, thus work well in JACK (though never as many as we wish we had). The favorites as far as I can recall (it's been a while since I've bought equipment are the Delta 1010 and the low-budget 1010LT (ten in, ten out), and a few other well-known brands (edirol, steinberg and even some amateur hardware such as creative labs -- check the matrix at http://www.alsa-project.org/main/index.php/Matrix:Main).

It's quite an adventure to get it all together, and I spent a couple of days understanding everything only to get the first few seconds recorded, but it's a nice journey.

the kernel application binary interfaces are a moving target.

That's why we have glibc, which abstracts that ABI from applications.

Kernel driver interface - the horse was already beaten to death many times ( see here ).

a consistent configuration system, to enable distribution;

Windows tried that with Registry - and it didn't worked. And it will never work since "one size never fits all" requirements of all applications.

native file versioning;

Was tried many times before and failed miserably. As long as majority of files are blobs, versioning on level of file system makes no sense. Versioning on level of applications is implemented already more or less everywhere it was needed and SVN/git is there for the rest of applications.

audio APIs;

See ALSA and its user-space libraries.

See SDL.

and the integration of X11 with apps.

As was shown by FreeDesktop initiative not really needed nor X folks want to be bothered by all the end user bells and whistles.

Finally, he argues that Linux needs a committee to insure that all GUIs work consistently and integrate better on the back-end with the kernel.

Committee?? Buahahhahahaha!!!1!!cos(0)!!!!!!!

All what he says was tried before (see (11)) and generally can be described as "failed".

consistent configuration system

What a dope; because we know this has worked so well for windows. The registry is a nightmare on Windows. Linux/Unix does have a consistent model and it is known as text configuration files. It's powerful and can be leveraged on even the slowest of links. One size does not fit all - although I've seen far too many applications use XML for this where it makes absolutely no sense whatsoever.

native file versioning

Seems Linux is now held to a higher standard. Again, what a dope. Outside of the VMS crowd, I've not seen a huge outpouring of demand for this feature. Having said that, I do believe a versioning FS is in the works and for all I know, some may already be available. Realistically, few people want this and most have no clue what it even means. For the general use case, RC-software already exists to fill this niche. His complaint is empty.

audio APIs

As far as I'm concerned, it's done. Pulseaudio and ALSA are all that you need. If you have more specialized needs, then JACK Audio takes care of you. For the majority of people, Pulseaudio has what you need and is also portable to Windows. Many (most?) distros are already moving or have completed their move to Pulseaudio. As far as I'm concerned, this issue is addressed, save only for migration time for slow adopters.

integration of X11 with apps

This means nothing. What a dope. All GUI applications which communicate with X are integrated.

and integrate better on the back-end with the kernel

Again, what a dope. This means nothing.

In a nutshell, his complaints are silly, meaningless, or have been addressed. As far as I can tell, his only complaint which has any merit is audio API standardization and that has been achieved.

An ALC268_ACER_ASPIRE_ONE entry is available in 2.6.28-rc2 patch_realtek.c, too, IOW ALSA git pull request obviously has been handled and I'll now have to test 2.6.28-rc2 to see whether it really works.

Beta Linux driver: http://alsa-project.org/main/index.php/User:ClemensLadisch

Other info: http://forums.techgage.com/showthread.php?t=3031

I'm still running a Creative Audigy 2 ZS with pretty good Linux and Windows support. Do the Creative X-Fi cards still lack Linux support? If so, one of the Asus cards may be the one to get for both Linux and Windows support.

Does it work in Linux? X-Fi on Linux is terrible at best and doesn't exist at normal. Can someone some insight as to whether it works in Linux or not?

I was just checking it myself and seems like ALSA supports the card allright. I've been interested on a high quality, cheap soundcard because of my main gripe with onboard audio: noise levels. I can hear hiss through my nVidia onboard audio adapter (which otherwise sounds damn fine), and even faint pop and crackles when the HDD is doing heavy work.

Actually the DX is supported. If you RTFA, there is no difference between the AV100/AV200. They are both using the CMI8788 audio processor. (C-Media Oxygen HD). Heres some info on the snd-oxygen driver, and the author's status page.

http://alsa-project.org/main/index.php/Matrix:Module-oxygen

http://alsa-project.org/main/index.php/User:ClemensLadisch#CMI8788_driver_status

Actually the DX is supported. If you RTFA, there is no difference between the AV100/AV200. They are both using the CMI8788 audio processor. (C-Media Oxygen HD). Heres some info on the snd-oxygen driver, and the author's status page.

http://alsa-project.org/main/index.php/Matrix:Module-oxygen

http://alsa-project.org/main/index.php/User:ClemensLadisch#CMI8788_driver_status

... complete now:
http://www.alsa-project.org/main/index.php/Matrix:Vendor-Asus
http://hg.alsa-project.org/alsa-kernel/

... complete now:
http://www.alsa-project.org/main/index.php/Matrix:Vendor-Asus
http://hg.alsa-project.org/alsa-kernel/

Well, the Xonar D2X should work, whereas the Xonar DX not yet it seems: http://www.alsa-project.org/main/index.php/Matrix:Vendor-Asus Since the hardware is so similar I guess it shouldn't take too long but I don't really know...

The DX employs what's marked as an Asus AV100 audio processor while the D2X uses an AV200. Don't pay too much attention to the names silk-screened onto the chips, though; they're the very same C-Media Oxygen HD audio processor under the hood. Asus says the chips go through a "quality sorting" process to separate the AV100s from the AV200s.

http://bugtrack.alsa-project.org/main/index.php/Matrix:Vendor-Asus The alsa wiki suggests that the DX is not supported yet, but the D and D2X are (and appear to use a newer chipset to boost).

In progress

http://www.alsa-project.org/main/index.php/Matrix:Vendor-Asus

Last I heard the higher end Xonar cards are nearly feature complete. I'd expect this to be working fine in the coming months.

The DX employs what's marked as an Asus AV100 audio processor while the D2X uses an AV200. Don't pay too much attention to the names silk-screened onto the chips, though; they're the very same C-Media Oxygen HD audio processor under the hood. Asus says the chips go through a "quality sorting" process to separate the AV100s from the AV200s.

If I recall some old experimentations, this is quite feasible technically with my good old SBLive and ALSA, by breaking out the outputs as different sound cards in your .asoundrc. Anybody got details?

And yes, I realize having something "techically feasible" is completely different from "work like a charm with the click of a button" :)

The drivers are provided as source, and usually compiles fine regardless of processor mode. Only a few drivers has been created bone-hard 32-bit.

From my point of view and experience with PulseAudio, it's most of the times ALSA, which is not communicating correctly with PulseAudio. Also PulseAudio's HAL module seems to have some problems too. See this bug report from ALSA: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2601

Also Ubuntu is just beta, so it's not stable yet. Also because of the problems existing with the current audio situation on Linux, it's a good decision to make PulseAudio default. It has communication layers with almost all possible audio servers/API's on Linux. It has good sound mixing capabilities. It can transfer audio via network, which is also an advantage for LTSP. It is cross-platform compatible, so it runs on Windows as well. So eventually it will make things a lot easier for managing audio stuff.

I hope they will improve the compatibility with PulseAudio. Also I hope that Skype will get support for PulseAudio.

Professional audio? Don't even bother. ESounD, ARTS, JACKD, now PulseAudio seems to be the big name in useless sound daemons...but that doesn't mean everyone will standardize on it. As if we needed yet another sound daemon anyway. If the Linux kernel is supposedly so "flexible" that it can be used in any range of devices from computers to cell phones, then why is it that 18 years or more later after the first release, there -still- isn't an easy way to do very low-latency, high quality audio recording on Linux? Linux distributions could _EASILY_ supplant a lot of the Windows based environments for professional audio if the kernel was up to the task. And for those out there who think that Audacity and Ardour are adequate replacements for ProTools...wake up.

I don't know about the rest of your points, but I can definitely argue this one.

If you're looking for "easy" low latency audio recording, I'd think Ubuntu Studio or 64Studio or a host of other alternatives would give you easy access to a preinstalled low-latency kernel and all the audio/video tools you need to make your own high-grade recordings.

Just because Pro-Tools is the piece of software which is handed out with most pieces of pro audio equipment doesn't mean there's no support for them.... My studio has been powered by ardour and JACK for the last few years, and I've been watching more and more people pick up this software. (See the forums and donations flooding into PBD on the ardour page for evidence of this.) Whereas I may have agreed with you a few years ago, saying that "ardour isn't a replacement for protools", I don't think that really holds water anymore. If you really have knowledge of some feature that you want in ardour so badly, go and put your money where your mouth is. I'm sure Paul would appreciate the support, and you'd get the features you want. </shameless plug>

(As an additional anecdote, one of my friends was going to school for audio engineering and mixing in Florida, and mentioned that the school he was going to actually *encouraged* use of Ardour and friends down there ... )

Also, please don't bring audacity into a pro audio discussion. There are plenty of better tools for handling audio than audacity unless you're doing cutting or other simple tasks -- it's more of a "Cool Edit Pro" replacement than anything.

I second your opinion, but I also want to point out the hard work done by Linux Audio Developers.

For one, they pushed the development of preemptible and low-latency Linux kernel to make it possible to do low-latency stuff, even on relatively aged hardware. Mac OS X's micro-kernel architecture is potentially superior in this regard because you can easily go hard real-time with micro-kernels (Linux is a monolithic kernel), but Linux kernel is more suitable than Windows XP for running audio applications because of these improvements.

They also obsoleted OSS (open sound system) and came up with ALSA, which makes it easier to support new sound devices from the developer's point of view. ALSA supports a range of consumer to professional sound cards, just like CoreAudio. It just works.

Another notable framework, JACK, goes beyond CoreAudio by providing audio routing between applications, like ReWire. JACK is also available on Mac OS X, except it is less robust than on Linux. Thrashing can cause audio drop-out because Mac OS X kernel can't lock pages in real memory.

Finally, if you ever considered audio production work on Linux, you definitely know about Ardour at some point. It's the hard work of Paul Davis, working on it unemployeed and full-time for many years. Ardour also runs on Mac OS X, by the way, because of the generous nature of Linux developers for offering you a choice.

If you do mostly recording, then you can get by on Linux quite sufficiently. If you do a lot of synthesized stuff like Reason or NI, then you'll be disappointed. There is simply no comparable app on Linux.

------

On the other hand, Linux has a lot of architecture catch-up on the graphics stack. Cairo recently has some talk about supporting more color spaces than RGB. However, the lack of end-to-end color management is a serious issue. Colors you see on the screen simply will look different when printed out. The colors are also not even consistent from monitor to monitor.

One thing I'm really impressed with Mac OS X is its monitor calibration. It lets you fine tune gamma by inspecting the monitor response in highlight, mid-tone and shadow for red, green and blue. I can easily color-match two monitors by different manufacturers.

Mac OS X also has superior built-in typesetting support, completely unparalleled by any operating system, and this is available in any application even TextEdit. In TextEdit, you can already turn on common ligatures like "fi" and "fl" as you type. In comparison, you must insert ligature glyphs manually when using Microsoft Word. Mac OS X supports more typesetting feature than that. For example, the Hoefler font has an archaic font variant with a "long s" (so congress looks more like congrefs where the f has shorter middle bar---the s at the end of the word remains the usual form because the long s is a contextual ligature that happens only in the middle of a word) and the "st ligature" (there is a small hook that goes from the top end of s to the top stem of t). Needless to say, contextual ligature is a crucial feature to support scripts like Arabic.

Mac OS X definitely has received a lot of attention in the aesthetics that goes way beyond eye candy.

Im personally under impression that ost if not all highend soundcards that are supported under linux are working because they have Alsa support. Check http://www.alsa-project.org/alsa-doc/ for more details.

wow am i an idiot. itchy trigger finger i guess; this is what i meant: http://bugtrack.alsa-project.org/main/index.php/Ma trix:Main

whoops! even better: http://www.alsa-project.org/alsa-doc/

i'm no expert, but i believe any hardware supported by alsa/jack should be supported by ardour, as ardour doesn't talk directly to the hardware. try http://www.alsa-project.org/alsa-doc/

As far as the MOTU goes, I don't think it will work. To look for your specific card go here to see if it is supported by ALSA. There is a DSSI plugin that will allow for use of VST plugins. I have not tried it so I can not condone or condemn the use of it. I am in a fortunate position with the music work I am doing on Linux. I need a new sound card, so I can browse through mailing lists and see what will/won't work before I purchase anything. All of my VST instruments and software was given to me by reps, so there will be no money lost. Good luck!

M-Audio is well supported by ALSA. Sauce.

Happy to have provided the links.

This is one of the best places for linux related audio links:

http://linux-sound.org/

I use a delta 1010 sometimes and an alesis multimix8usb sometimes. Plus, more generic and onboard sound cards.

If you want to see if your sound card is supported, check this link:

http://www.alsa-project.org/alsa-doc/

Plus, with studio to go at the link I provided:

http://www.ferventsoftware.com/

it says this:

"The Studio to Go! Demo Disk is now available for immediate download!"

and

"You can use this demo to check your sound hardware for compatability and take an introductory tour, listen to demo songs as well as try composition to get a feel for how the package works. You're free to play with any of the included applications to your heart's content."

So you can test your hardware and mess around some without having to install anything, it is a "liveCD" dealia. There may be others, demudi or dynebolic from memory, don't trust my remembered spellings...

all the best,

drew

It uses the ancient and deprecated OSS audio interface instead of the modern ALSA. This means you have to buy an expensive sound card with hardware mixing, or put up with only one program being able to play/record sound at a time.

The M-Audio Revolution 5.1 and 7.1 cards seem to be rather popular with Linux geeks, and ALSA support for them is second to none, apperantly.

But please check out the list of supported sound cards on the ALSA site. Plenty of choice, I would say.

still lacks kernel audio mixing So does Windows, though. Neither Windows nor Linux uses kernel audio mixing -- they rely on hardware mixing instead. All somewhat modern sound cards have several PCM subchannels that operating systems use in order to play several sounds simultaneously, and, yes, it is perfectly supported by Linux. Last I tried (admittedly, that was some time ago, but I can't remember just how long), using Windows with a single-channel sound card meant that I could only play one sound at a time.

I'm sticking to GPL projects because I don't know about other ones as well. This is not meant to diss the BSD crowd.

• ALSA everyone welcome to submit a driver for their card. I might add that most Linux Kernel drivers and most drivers for a number of other projects (X, CUPS, gcc backends, etc.) are fairly open and you can jump right in.
• gentoo packages you might not get into the main distribution right away, but the community is very open and will try out pretty much anything you have to contribute. Like drivers, above.
• GIMP and GTK at least, pre-2000. Now there are a lot more developers, so jumping in isn't quite as easy.
• kino has a very flat hierarchy. linux1394 is the same. Like drivers, above.
• MediaWiki

Okay, but I also think that cataloging open source projects is kind of fruitless, since there are so many. The internet connects people with common interests. They develop projects. Some are more open than others. Still, if the project gets too rigidly hierarchical, someone will fork the code and head off in a different direction. Example: the different flavors of BSD.

At the Dutch Electronic Arts Festival (DEAF) I attended a session with Paul Davis, author of Ardour DAW, and he was using RME Multiface.. Hardly a shitty soundblaster, I'd say, although I do think he coded the alsa driver himself.

RME cards are well supported under Linux w/ ALSA and they definitely fall into a superior category...

Yeah... I would say that the ALSA (Advanced Linux Sound Architecture) project being intergrated into the Linux kernel is going a long way to improving the audio experience beyond what Windows can ever offer. (With the exception of audio boards that aren't supported by ALSA for the usual corporate non-disclosure reasons) I have a semi-pro audio system (Echo Layla 20) that wasn't supported fully (I needed MIDI, not just audio) for a while so I still had to run XP. But now, I've been able to ditch it and the only thing that keeps me on Windows is video editing. Of course, per my latest journal entry I am trying Cinelerra in the hopes that I can finally ditch that one last reason to run Windows. Everything else that I do (and there is a lot) can be done in Linux and I only need Windows for that last thing.

Check to see if your Terratec card is listed here. However, I will admit that getting sound "right" under Linux with some of the high-end cards can be tricky (my brother's machine has an Envy24-based card).

Credit, where credit is due: Go here if you want to gripe about resolution issues.

And should I even mention the fiascos with various sound cards that you just didn't want to play nicely with?

Go here for support with your sound card.

Or of the hardware that you were supposed to be "known-good" on that you chose not to work with at the most inopportune moments?

Don't buy cheap hardware or anything newer than a year old. If you want bleeding-edge new stuff, stick with Windows or Mac OS.

Most of your gripes should actually be directed at the specific Linux *distribution* that you chose to use. The distribution choice is a whole religion unto itself. ;P Of course, I choose Fedora because it "just works" for me. My definition of "just works" = take the base distro and install it minimally. Hand compile everything I need. Tweak the system for what I need. Turn it into any of the following:

1. GNOME Terminal Server
2. Thin client (using cheap wireless laptop)
3. PVR/Entertainment system
4. GASP!!! A desktop computer!!

Sorry, but it "just works" for me. :)

Here is what I've found in my own informal comparison back in 1998:

-Setting up a Windows 98 box to do everything I need: six hours and about $3000 worth of extra software. (I'm not a pirate, so I buy everything I need) Considering how a lot of the functionality included with Windows XP is low grade compared to full commercial products (ripping CDs, editing images and video, etc...) and the fact that software costs even more now, I'd have to spend at least $3000 extra to do the things I want.
-Setting up RedHat 7.0 to do everything I need: six days and $0 worth of extra software because RedHat 7.0 came with everything I needed at the time. Considering that Fedora Core 3 has moved lightyears beyond RH 7.0 it's only that much easier now. So the same setup might take me three days now and probably a lot less since my knowledge has improved since 1998.

That's the key to using any Linux distro. You have to dedicate the time to learning it. Keeping in mind that the trade-off is that you wind up spending very little to no money on software. I'd say that's a significant feature that Windows can't compete with. Mac OS is in a flux right new due to the IBM to Intel CPU switch. I wouldn't touch a Mac with a ten foot pole for the next two to five years. Granted Mac OS is beautiful and can host a lot of the apps I use in Linux now, it's not worth buying a box that's only going to last a few years. Currently my Linux based GNOME terminal server is a dual P II 233 with 768 Megs of RAM from 1998 and it runs just as well as a P4 running Windows XP Pro. It can do everything that a Windows XP box can and more. So, it does "just work".

This depends on what soundcard you have. Most should be supported, but there are a few exceptions. The nForce MCP onboard audio, for example, needs a binary driver from nVidia to get sp/dif working.

Check out the Alsa soundcard matrix at:
http://www.alsa-project.org/alsa-doc/

That should let you know what the status of support is for your soundcard.

If I imagine a noise and manipulate the controls of Rosegarden expertly, will I get the noise that I'm looking for?

To be able to do that, you'll probably want something like a modular softsynth. For Linux, there's ams. That combined with a virtual keyboard like vkeybd is enough (given the "expert manipulation" part). Something like Rosegarden could then act as the "player" of the synth (which is like the "instrument").

If you really want to get down to the bits and bytes, there's pd.

The easy road to all this is to install the AGNULA Linux disribution, which comes with a shitload of software.

Go to http://alsa-project.org/ and have a look there. In Linux you don't normally get your driver directly from the manufacturer---it's better to get it from your distribution or from some central repository like this that can tell you how to install it for your system, and not some one driver fits all `system' like in Windows.

I'm not sure when, but the alsa people finally did allow kernel level sound mixing (for applications that have native alsa support only). Speaking of difficult documentation, find dmix on that page.

in your situation:
run 'lspci'
find the line that corresponds to your soundcard.
go to http://www.alsa-project.org/alsa-doc/ and follow the instructions

The ALSA sound driver works quite well, except that the AC3 stream delivered through the SPDIF output is not recognized by most AC3 decoders. (check ALSA bug 411 for details: https://bugtrack.alsa-project.org/alsa-bug/view.ph p?id=411)

In this case, the problem comes from Soundstorm stuff which prevent ALSA driver from correctly setting the hw (Namely RealTek's ALC650 chip which has public specifications).

One of the ALSA developer is quite sure to be able to reverse-engineer Nvidia's audio hardware, but he has no hardware to work on.

Would it be correct to start another thread to ask for a donation for this guy ?

It'd be great to see realtime capabilities in the vanilla kernel - though in the meantime for a low latency Linux multimedia system I recommend the Planet CCRMA low latency kernel based on Fedora/Red Hat - this has a huge repository of compatible software, much of which is of very high quality. See Ardour (Digital Audio Workstation) for instance. Planet CCRMA uses the Advanced Linux Sound Architecture (ALSA) drivers (which have OSS emulation).

Here's what you get when you follow the link on the ALSA site to latest documentation. Pretty good, hunh?