Innovation is still happening on the OpenBSD and DragonFly fronts.

FreeBSD is all about incorporating other people's software at this point (ZFS, DTrace, LLVM), and hasn't really originated a good idea in a decade. Coincidentally, that is where DragonFly split off. That's what happens when Apple buys the FreeBSD development team...you get a bunch of core developers running FreeBSD in a virtual machine on MacBook Pros. They can't be bothered to get basic functionality like suspend/resume to work, and all new wireless drivers are lifted from OpenBSD.

NetBSD is dead.

Regarding the summary, PulseAudio adds nothing to the *BSDs...OSS has always been able to have multiple programs access the sound card at the same time. Avahi runs fine at least on OpenBSD, and systemd....well there are only about two Linux distributions even using it at this point.

Seriously you're asking a linux developer his opinion on BSD? What answer were you expecting?

Something that doesn't make him sound like a complete idiot?

The core of Mac OS X borrows heavily from BSD, so one could legitimately argue that BSD is now the most widespread UNIX variant. In fact, I wouldn't swear to it, but I suspect that makes BSD (and Mac OS X, specifically) more popular than all of the other Linux and UNIX variants put together.

You'd pretty much have to be living under a rock to think that BSD isn't relevant. Either that or you have to believe that Windows is the way of the future. Take your pick.

I don't blame him for creating PulseAudio. I blame the distribution maintainers for having the poor judgment to make it the main sound system for so many distributions. It would be one thing to have a sane default like ALSA and then have PulseAudio available in the repositories for those who really want it.

For my friends who use Linux, the first thing I do whenever a new distro is installed is to check if it is using PulseAudio. If so, I remove it and replace it with ALSA. Suddenly issues related to audio playback go away and everything just magically works. Oh and they easily have a proper mixer without jumping through hoops, too, which is handy considering some of them are using 5.1 surround sound and/or bluetooth headphones.

The first headache I had with PulseAudio was when I tried to run something as a different (normal) user account and audio wouldn't work. There was no meaningful error message. There was only a "connection refused" error in the terminal. As it turns out, this is because PulseAudio has to be run by the user and it is recommended not to run it as a system-wide daemon. User A was running the user-daemon and User B was denied access to it as a consequence. They both could not run their own, well they could but it wouldn't work, as that'd be far too easy. Rather than screw around trying to get that to work I just used ALSA since PulseAudio didn't do anything I needed it to do that ALSA couldn't do with none of the hassle.

In case you wonder why I was running something as another normal user, it was for using Windows programs in WINE. I always prefer to do that with a separate user account that isn't used for anything else. This special WINE account has additional restrictions because I do not trust Windows programs -- they might phone home, they might contain malware, they are binary blobs that cannot easily be inspected, etc. The point is, Unix and therefore Linux are multi-user systems. You expect to be able to have multiple concurrent users running programs without issue.

PulseAudio smacks of the walled-garden model, where as long as you are a very average user who does extremely predictable things that they have decided to allow for, such as only having one active user on the local system, then you have few or maybe no problems. As soon as you do anything even the slightest bit unusual (which multiple users on a *nix system hardly is) you start running into brick walls. To that I say "no thanks, not for me". If I wanted that experience I'd use Windows. If ALSA were a barely-functional, poorly designed sound system I could at least understand why PulseAudio exists and why it is becoming so popular. As far as I can tell it's a burdensome solution to a problem that doesn't exist.

He has a tendency to develop things halfway, without taking any input from any users, and then everyone using Fedora has to end up using it even if it's complete shit. If you criticize him, he's got some staunch defenders that will call you out on it, mostly the people who have only ever used Linux on a laptop... that really does seem to be the only thing he cares about.

PulseAudio - a useless NIH layer. ALSA was just fine. He lists a bunch of other problems with Linux audio, but everyone was just using ALSA directly, nobody was using his straw men really (Jack? OSS? Really?) This is the first thing I remove on my Linux boxes.

I predict systemd will be his next "hit". He named the control command "systemctl" even though every Linux has a "sysctl" command already... one of the most easily avoidable CLI namespace problems I have ever seen in over 20 years of UNIX and 18 years of Linux administration. I think systemd is because he really really wants to make Linux into MacOS X. If you want MacOS X, then great, it's a fine desktop OS, have at it.... but Linux is still mostly used on servers, and there is nothing wrong with that at all. Anyway, systemd just throws out everything that was good about init and even upstart, and starts over, and he is busy adding the features of cron and inetd to it for some reason. Because saving some tiny amount of space in the process table is somehow useful.

I just wish there was some review of features that make it into Fedora, etc, to see if they're really worth it.

back in the late 1990s, i had a flamewar on an irc channel with a guy from redhat, screaming at me that there was no reason anyone would want to have two programs play a sound at the same time.

If the goal is to get rid of problems caused by ALSA (I'd love to hear what those are, by the way) ...

Not that PulseAudio would necessarily solve these, but here's my list:

(1) The default dmix resampler sucks. The "high-quality" one is better, but that one uses up significant chunks of CPU time. I haven't had a chance to look at the code (been meaning to) but it seems to me it should be possible to maintain quality without using so much CPU.

(2) Semi-pro home-studio type soundcards are poorly supported. Currently my ENVY 1712 does not come up right on boot and it takes an iteration or two of unload-modules and restart alsa before it "catches". Seems something broke somewhere between 2.6.32 and 2.6.38. Alas I need the latter to support this motherboard.

(3) After audio's been playing for an hour or two, I'll start to get some crackling in the left speaker. Unloading modules and restarting alsa fixes it.

(4) The resampler/dmix semantics are dumb given that many soundcards can run at any of the popular sampling rates up to 96K. A smarter way to do the mixing is: when no other sound is playing and an application asks for audio, set the card to run at the same rate as the source to be played. No resampling required. If and only if a second sound source wants to come in while sound is currently being played; and if this second source asks for a rate different than the one currectly being used, then and only then the resampler is started and used to match the second sound's rate to the first.

Most the time this does what you want: music being played will sound as clear as possible. Any ancillary system boops and beeps and desktop sounds that come in the middle will get resampled if needed. And you won't be burning CPU except when needed, and only for the relatively short ancillary sounds.

(5) Perhaps there's a way to configure the behavior desired in (4), but the alsa configuration language and options are so dense and (to me) counterintuitive I don't know where to start. It is like a programming language onto itself but there's no idea of what options are relatively efficient to use, and what should be avoided if possible.

(6) Related to (5) and indirectly to (4), there are time I _want_ exclusive use of the audio, without any mixing. I live with several roommates; we rotate around who plays mood music in main room. When I'm playing audio in this manner, the _last_ thing I want is to be shocked out of my seat when I inadvertantly visit the "wrong" web-page that blasts some sounds. What's the best way of expressing this in alsa-lingo?

(7) The Jack-audio-connection-kit realtime audio router seems to solve a lot of the same problems as dmix, and as PulseAudio. Why didn't they just use that? I get much better results when using Jack. Admittedly, Jack runs on top of alsa, so what's Jack doing that the apps aren't outside of Jack?

Some of these may well be PEBKAC. I apologize but find the documentation is simply too dense and obscure for someone who doesn't yet have a grasp of just how all the pieces interact that I may know where to look and what to tweak - or, even - what pieces are available. It didn't help that I was trying to set up audio right around the time dmix entered the picture and what I thought I knew one week no longer worked the week after, which has put a rathar sour taste in my mouth over the whole thing.

Apple is due to report quarterly earnings next week. Guesses are that they will have sold around 18 million iphones and 8 million ipads, maybe 5-6 million iPod touches. Comes out to a ballpark of roughly 360k activations a day.

Is it just me or is it almost unbelievable that between iOS and Android there are almost a million devices being activated every day? Amazing...

ALSA and OSS always just worked for me.... all the way back from the first time I tried audio on Linux with OSS on a 1.0.x kernel. I have been using Linux daily as my main desktop OS since 1993, with a variety of soundcards (mostly Soundblasters and recently more onboard integrated audio, but also a variety of other cards), and I'm telling you, I never had the problems PA was supposed to solve with just directly using ALSA. Now I get fewer functions and PA uses more CPU. Great. Removed.

Regarding systemd:

System-V init actually does exactly what a Unix-like system needs it to do... but regardless of that, my problems with systemd are:
1. If you even suggest for a second that systemd isn't awesome, you will hear from people (for example.... you) who says it's great, without addressing any concerns that system admins actually have.
2. The command line interface is annoying... it's even worse than the problems we have with SMF on Solaris 10+. Following the original threads about it, you can tell Lennart has no idea what people actually do with the command line. systemd calling $MORE? Hasn't anyone ever used expect?
3. They want to roll cron and inetd into it... for no reason that I can see. Vixie cron and xinetd both work great last I checked. This seems to be bacause that's what MacOS X does with launchd, not for any real reason.
4. Doesn't socket activation require changes to daemons?
5. D-Bus dependency. On my init system. Sounds awesome, where do I sign up. systemctl actually didn't work at first on my F15 box because... I don't run dbus (standard X11 window manager, I don't generally use Gnome or KDE, lucky me.)
6. Optimizing for a problem most Linux boxes don't have... reboot speed and dependency resolution, which really sounds like something I do as little as possible. I run 100s or 1000s of boxes... reboot speed is rarely my concern... my boxes spend more time in POST then they do mounting filesystems and starting sshd these days. Sounds like a laptop problem to me.
7. No separate /usr... and when you ask about it you're told "you don't want that." Now, I don't ever separate /usr if I don't have to, but I do not think that is an adequate answer, and I know people this is going to seriously affect at some point.

My concern is that systemd is going to make it into CentOS and RHEL at some point, and that will suck for me, unless Redhat actually makes some changes to it.

Am I still talking nonsense or are you just blind?

This issue has been going on for a long time, and each time a BSD developer asks to see solid docs so that he/she can port the API to be used on FreeBSD they get a bunch of incomplete specs that are absolute shit.

http://gezeiten.org/post/2011/01/Xfce-4.8-on-BSD-flavors#c14587 [gezeiten.org]

Warner Losh asking for good specs to implement udev on top of devd which has done the things that udev now does for years.

From what I've read about systemd the most irksome part is that every daemon that wants to really work well with systemd must undergo quite some code changes. Otherwise, that particular demon will be handled like in the old init system. So, in order to bring any benefit at all, the whole system (which worked) must be adopted to systemd in some way. Given that some of these demons are really there to be run on servers where systemd has no place, this thing does not seem like a very good idea.

But unlike PulseAudio, i haven't had a chance to see systemd fail spectacularly.

Working audio was what made me switch to FreeBSD in the first place. This was back around 2001. The state of the art was something like this:

Applications played sound by writing writing to /dev/dsp. This was a fairly standard way of playing sound, based on the Solaris, and supported by most *NIX systems. OSS defined a set of ioctls for controlling playback, and these worked everywhere. There was one slight problem: most implementations didn't support software sound mixing if your hardware (like most cheap AC97 CODECs) couldn't do mixing in hardware. This meant that only one device could write to /dev/dsp at once, meaning only one application could play sound. KDE and GNOME both had their own (incompatible) sound daemons, so multiple KDE or multiple GNOME apps could play sound at once, but not both. I was using a KDE Jabber client, a GNOME email client and wanted to get audio new message notifications from either. I also wanted XMMS (which wrote directly to /dev/dsp) to play music in the background, and I wanted to play BZFlag! sometimes and have its sound work without breaking anything else.

In Linux land, there was ALSA. ALSA did sound mixing, but it required your applications to be rewritten to use it. Some sound cards only had ALSA drives, some only had OSS drivers. A few had both. ALSA had a half-arsed OSS emulation mode, but that broke various other things, and still didn't let multiple OSS applications play audio at once.

FreeBSD 4 had a virtual channel (vchan) mechanism. You had several /dev/dsp.n devices. /dev/dsp was a symbolic link to one of them. I set the KDE sound daemon to use /dev/dsp.1, the GNOME one to /dev/dsp.2, XMMS to use /dev/dsp.3, and whatever other app tried to use /dev/dsp got the /dev/dsp.0 channel (typically games, running in the foreground). All of my running apps could play sound at once and, after a small amount of initial configuration, it Just Worked.

I didn't stay with FreeBSD 4 for long on the desktop, I started using the FreeBSD 5 betas. This was a really unpopular FreeBSD release, because it was only about as stable as Linux at the time, which most FreeBSD users felt was completely unacceptable. It improved the sound system so that the vchans were automatically allocated. Now, things worked just as well as they did with FreeBSD 4, but I didn't need to configure anything. Apps could just open /dev/dsp and they'd each get a new vchan, up to a configurable limit (I set it to 16, which seemed to be more than I needed).

Now I use FreeBSD 8. As well as the earlier features, it has a new low-latency sound mixing path, per-vchan volume controls, and full OSS 4 support. Oh, and it even has a compatibility layer, so if I run old code that uses the OSS 3 APIs and tries to modify the global volume control via /dev/mixer, I can make it only modify its own vchan's volume.

Meanwhile, Linux developers were told that, actually, they shouldn't use ALSA, they should rewrite their sound code yet again, this time for PulseAudio. And people wonder why I hate having to support Linux...