On Thu, 2007-10-11 at 20:31 +1000, Jan Schmidt wrote: > <quote who="Ronald S. Bultje"> > > > Daemons for sound routing are not just suboptimal, they are wrong. We > > have > > better ways (at least on Linux) nowadays. Any solution based on the idea > > of a userspace daemon is wrong. Not just suboptimal (which is > > unacceptable, because ALSA directly is - for Linux users - very much so > > optimal, and that's 90% of your userbase), not just "still somewhat > > acceptable" (because it isn't, we've ditched esound for that very reason) > > and definitely not "required because a small subgroup of your user > > population needs it" (crippling for the sake of network users - yeah > > right). > > I get so sick of people saying "but I don't *want* a sound daemon, ALSA can > do it all!". It's so irritating because ALSA's solution for mixing on the > vast majority of modern sound hardware is to have to use dmix, and *dmix is > a sound daemon* - it's fundamentally doing *exactly* the same thing that > pulseaudio does, except that it forks whichever process happens to open the > audio device first instead of being an explicit separate binary.
You are mistaken. ALSA dmix does not require any daemon. I suspect it uses SYSV IPC to make all processes do some kind of distributed mixing, with no daemon required. > Plus, it traditionally hasn't even done a very good job of being a sound > mixer. It does crappy resampling, gives poor feedback on the number of > unplayed samples and drops out just as much as a normal sound daemon because > it's just a process with normal privileges - all problems that PulseAudio > doesn't have when configured correctly (configured so that it can obtain > realtime privs, that is). Even if dmix is buggy, why can't it be fixed instead. And not to mention that even my desktop PC with ultra cheap motherboard has builtin sound which supports hardware mixing. I am pretty sure I'm not using any kind of software mixing at the moment: neither dmix nor esd nor pulseaudio. I just think that, by default, users should be given a chance to experience audio with hardware mixing, if the hardware supports it. But most importantly, I wouldn't mind PulseAudio too much *if it worked correctly*. As it is now, maybe it isn't PA's fault, maybe it's the linux kernel's fault for not having a good enough process scheduler, but the sad truth is that PA's sound skips (I mean I hear audio clicks when switching workspaces). I believe when people say it doesn't skip for their hardware, but I expect people to believe me when I say it does skip for me. > > And of course there's the things the PA can do that bare ALSA never will: > * Sample caching > * Low latency per-process volume control. > * Graceful handling and policy for on-the-fly device removal and insertion Those are nice features, but all summed together they don't come near to "skipless sound" that raw ALSA provides. > * Decent OSS emulation that doesn't cut software-mixing out of the loop OSS is deprecated. > * Drop in esd replacement for backwards compatibility. I already do not use esd. > And last, and actually one of the minor features: networked audio. That should be an extra layer *on top of* basic sound, not a replacement layer. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> "The universe is always one step beyond logic" -- Frank Herbert _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
