On Thu, May 20, 2010 at 5:08 PM, Nikos Chantziaras <rea...@arcor.de> wrote: > Because as soon as you disable ALSA dmix and/or Pulse, suddenly you get > acceptable sound latency. > > With OSS4, which has in-kernel mixing, it doesn't matter if you enable the > mixer or disable it; sound always has acceptable latency.
By that reasoning, the GUI should be in-kernel too. It would be then really responsive al the time. I don't buy the argument. > Thus, I can only conclude that mixing has to happen in-kernel. But I base > this only on the ALSA/Pulse vs OSS4 comparison. It could also be that the > user-space implementation of ALSA just sucks. But that's hard to believe, > since if that were the case they would have fixed it several years ago > already. No, it doesn't has to happen in-kernel; all the linux based phones (which deal primarily with, you know, audio, including heavy use of multimedia) use PulseAudio. And these are not very powerful machines; so if the mixing in user space works in low powered devices, it must work everywhere. I don't buy this argument either. > It sounds reasonable from a designer's point of view. But a system is > useless if it's only designed good but doesn't actually work in a > satisfactory manner. It works for me, I repeat, and for a lot of other folks too. It's not only a design decision made because it's "elegant"; it's made because it works "in a satisfactory manner" (ex. me, others, Linux phones), and because it's more flexible: put it in the kernel, and you loose the capacity to do important changes and extensions (specially with the way the Linux kernel development works). In short, because it works "in a satisfactory manner" (to me and many others, including all the N900 and Android users out there), I also don't buy this argument. > Sorry, that just pretentious of you here. PulseAudio is the most flamed at, > hated, sound-related software around. And this is because it does *not* > work for many, many users, and the first thing they try to do is find out > how to disable the thing. Sorry, but I believe the you are the one being pretentious; how long has been since you tried PulseAudio? It has come a loooong way, and I haven't seen any real flames against PulseAudio in many months (and it's enabled in all major distributions). And that is because it's working (I repeat my words) "for me and many more". > You're mistaken in that a mixer should be in the same boat as network > streaming, bluetooth, etc, etc. I believe the *mixer* should be in-kernel. > Everything else doesn't need to be. PulseAudio's extreme latency problems > (which even upstream admits can't be fixed easily) stem from that. I respectfully disagree; the kernel should pass along data and messages to the sound hardware, and everything else (*including mixing*) should be in user space. Not only in theory from an academic and aesthetic point of view; *it also works*, to me, to many users who doesn't complain (despite PulseAudio being used by default in ALL major distributions), and to ALL the users of Android and MeeGo. And to finish, I don't know how much you know about technical decisions and design, but I know that Linus refused to accept OSS4 in the kernel, I know that all major distributions decided to go with PulseAudio, and I know that Intel, Nokia and Google are betting for it. So, no offense, but I trust more in those guys and the arguments I have heard from them. And the consensus with them is to use PulseAudio, and leave the mixing in user space. Regards. -- Canek Peláez Valdés Instituto de Matemáticas Universidad Nacional Autónoma de México
