> <quote who="Gustavo J. A. M. Carneiro"> > >> > On Thu, 2007-10-11 at 20:31 +1000, Jan Schmidt wrote: >>> > > >>> > > 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. > > The first process to open the sound device is forked in alsalib and > *becomes* the dmix mixing daemon. Check it out in your ps listings. > All the other programs requiring access to mixing services then deliver > their streams to that process via a shared memory mapping. It ends up being > fundamentally the same as pulseaudio or esd with autolaunching. Unless you have hardware mixing. >>> > > 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. > > By separating the dmix piece from alsalib, I believe we can do better and > provide more. Get hardware mixing and don't use dmix at all. >> > 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. > > I think you are most likely wrong here. Every motherboard I've seen in the > past 4 years with built-in sound has used AC97 with a codec chip, and none > of them have provided hardware mixing support. You're probably using dmix > and just don't realise. Which means dmix isn't all that bad after all. But to get back to the original point of allowing hardware mixing if it exists on the sound card, I for one want this, it would definitely be abysmal if I couldn't use the hardware mixer on my au8830 and alsa does a wonderful job of supporting 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. > > The most likely reason is that you need to give pulseaudio the ability to > acquire real-time scheduling privileges, like you do for jackd, because it > operates with smaller hardware buffers to achieve lower latency. On a distro > that provides PulseAudio integrated, this should happen by default. Yes, there also are specific distributions finetuned for realtime work, but they are not always useful for normal work. >>> > > 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. > > See the real-time privs point above, or modify the PA config to have bigger > buffers. > >>> > > * Decent OSS emulation that doesn't cut software-mixing out of the loop >> > >> > OSS is deprecated. > > There are plenty of apps that use it though. That may not matter to you, but > backward compatibility is important. > >>> > > * Drop in esd replacement for backwards compatibility. >> > >> > I already do not use esd. > > You must have the Gnome desktop sounds turned off then. > Who wants to hear all those sounds while listening to your favourite music anyway, I for one never have the desktop sounds turned on. >>> > > 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. > > If you want to do it so that the apps don't have to know about it, it has to > integrate underneath them somewhere. But again, I don't see this as PA's > major appeal, it's just a neat side-benefit of building things this way. -- regards Robert G. Moonen registered Linux user number 298132 "All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident." Arthur Schopenhauer - German philosopher (1788 - 1860)
Attachment:
signature.asc
Description: OpenPGP digital signature