On 29 November 2010 00:08, Yaro Kasear wrote:

Once again, I say PA is far from the kind of quality I'd expect from a package in [extra], and I'm surprised the Arch devs are even considering it, especially in light of the fact that there's far more stable and useful packages in [community] getting passed up.

Once again, nobody asked for opinions on PulseAudio, the software. If it does affect you directly, do report that here or the bugtracker. It was moved to [extra] for package-specific reasons, not just on a whim as you would like to think.

On 11/28/2010 06:18 PM, Yaro Kasear wrote:

On Mon, 2010-11-29 at 00:15 +0800, Ray Rashif wrote:

...

On 29 November 2010 00:08, Yaro Kasear wrote:

...

Once again, I say PA is far from the kind of quality I'd expect from a package in [extra], and I'm surprised the Arch devs are even considering it, especially in light of the fact that there's far more stable and useful packages in [community] getting passed up.

Once again, nobody asked for opinions on PulseAudio, the software. If it does affect you directly, do report that here or the bugtracker. It was moved to [extra] for package-specific reasons, not just on a whim as you would like to think.

What packages actually REQUIRE Pulse Audio? I don't know of a single Linux app to date that actually NEEDS it over what already exists in ALSA itself.

dear Mr Yaro. I suggest to read again the first message from the list. It doesn't ask for opinions about pulse on how good or bad is. Keep your opinions for yourself. You are not forced to use pulse if you hate it, pulseaudio is optionally unless you are using gnome. Starting GNOME 3, we will include support by default. This it happened some time ago upstream but WE keep it out, until now. PLEASE, but PLEASE keep your junks out on my inbox -- Ionuț

On Mon, 2010-11-29 at 00:27 +0800, Ng Oon-Ee wrote:

On Sun, 2010-11-28 at 10:18 -0600, Yaro Kasear wrote:

...

On Mon, 2010-11-29 at 00:15 +0800, Ray Rashif wrote:

...

On 29 November 2010 00:08, Yaro Kasear wrote:

...

Once again, I say PA is far from the kind of quality I'd expect from a package in [extra], and I'm surprised the Arch devs are even considering it, especially in light of the fact that there's far more stable and useful packages in [community] getting passed up.

Once again, nobody asked for opinions on PulseAudio, the software. If it does affect you directly, do report that here or the bugtracker. It was moved to [extra] for package-specific reasons, not just on a whim as you would like to think.

What packages actually REQUIRE Pulse Audio? I don't know of a single Linux app to date that actually NEEDS it over what already exists in ALSA itself.

Gnome. But as you've already stated yourself, their devs are idiots. Since you obviously use KDE, as all other enlightened souls do.

I'm unsure on why you're directing such vitriolic hate on pulseaudio. 70% sound system breakage? Regression which causes more problems than it solves? Perhaps you should specify[1] what you're talking about rather than generalizing. That is, if you're interested in being taken seriously.

Split this off, its just noise to most, so I think many would just want to mute this new thread.

[1] - note, a 'google about pulseaudio problems' doesn't count as specifying. Googling 'linux problems' gives far more, but we don't take that seriously, do we? Or 'KDE problems', or 'some-piece-of-software problems'

GNOME 3 isn't even released yet. There's no CURRENT dependency in Arch, in [extra], for Pulse Audio. Fine, Then I'll list all of its problems right here: - It's unstable. - It's got far too many unresolved bugs the upstream developers defer INCORRECTLY elsewhere simply because they can't be bothered to fix their software. - It wastes a lot of RAM. - It wastes a lot of CPU. - It causes noticeable audio latency. - It DOES NOT release sound to other daemons as your erroneously claim. It will not turn itself off for JACK just as it won't turn itself off for ESD or Phonon. - It actually doesn't support ALSA that well, it's ALSA module is stuck at 70% completion, with a lot of critical ALSA support stuck on that missing 30%. Again, further upstream blame gets laid on ALSA or drivers where it doesn't belong. - It's not really necessary for any actual Linux audio needs, where things like ESD and Phonon had already fixed the problems Pulse Audio has no use for. - Even the Pulse Audio devs at one point admitted it breaks Linux audio. - A great deal of Linux applications have problems working with it, far more than any other daemon to date. Upstream, rather than making Pulse Audio abstract itself like ESD or Phonon does, seems to want app developers to write their code SPECIFICALLY for Pulse Audio, which is NOT how its done. - An incredible array of utterly useless features (Like networking sound in a day and age where all PCs have sound systems they can use themselves. Never count on networking where an actual local system will do.) that Pulse Audio fans never use bt love to brag about so they can distract from Pulse Audio's obvious problems, just like you are doing right now. - Much, much more, but you get my point. Maybe wait until GNOME 3 actually gets released before put something unstable and useless in [extra] needlessly.

On Sun, 2010-11-28 at 18:44 +0200, Ionuț Bîru wrote:

On 11/28/2010 06:38 PM, Yaro Kasear wrote:

...

Maybe wait until GNOME 3 actually gets released before put something unstable and useless in [extra] needlessly.

our experience in packaging software, fixing bugs and debugging is far superior than yours.

we have just made a small step in adding default support in gnome, instead of doing everything when gnome 3 is released.

In this way we can ensure that everything works before pushing this permanently.

Just understand, Pulseaudio is optionally

I do. Most my response is to the people who think Pulse Audio is the end-all Audio solution when it's far from actually being so (With the fact it's clearly not stable or mature enough for [extra] as part of this.). The opinion it should be a default for Arch, for example, or that it should be the standard for Linux are idiotic, since, as I stated many times before, Pulse Audio is crap that solves nothing and breaks everything. I'll stop posting on this topic now.

Let me answer on your points...

...

Fine, Then I'll list all of its problems right here:

- It's unstable. NEVER crashed on me... From the PA page: "Current Status The PulseAudio daemon and utilities are still under heavy development. Although they are generally considered stable, they haven't seen enough testing to warrant a first completely stable release." - It's got far too many unresolved bugs the upstream developers defer INCORRECTLY elsewhere simply because they can't be bothered to fix their software. Possible, tho i did not experience any... - It wastes a lot of RAM. never see it in top. It shouldn't, PA is also to a large degree developed for mobile phones. - It wastes a lot of CPU. see above. In fact it uses LESS cpu then pure alsa does here, since alsa is resampling everything, altho my card can natively play all samplerates. Pulse behaves correctly here and simply routes it forward. I'm rather sure PA resamples everything and with alsa it depends on the configuration. They might use different algorithms by default. - It causes noticeable audio latency. You cant be serious? i have been using pulse audio over network from one room to the next. It synced audio with my movies 100% even over a slow wifi network. This would never work with high latency audio backends... Low-latency is no goal of PA, its latency might change at any time or all the time, it simply doesn't matter for the use cases it is designed for. - It DOES NOT release sound to other daemons as your erroneously claim. It will not turn itself off for JACK just as it won't turn itself off for ESD or Phonon. - It actually doesn't support ALSA that well, it's ALSA module is stuck at 70% completion, with a lot of critical ALSA support stuck on that missing 30%. Again, further upstream blame gets laid on ALSA or drivers where it doesn't belong. I am actually not too sure about this one, since upstream alsa DOES have a lot of bugs that never get fixed. - It's not really necessary for any actual Linux audio needs, where things like ESD and Phonon had already fixed the problems Pulse Audio has no use for. Phonon has solved what exactly? Its totally useless overhead with not a single complete backend. Every single backend is missing features the other one has. - Even the Pulse Audio devs at one point admitted it breaks Linux audio. - A great deal of Linux applications have problems working with it, far You can simply forward alsa AS IS to pulseaudio - this should work for about any software you can think about. Btw: skype works much better with pulse than with alsa. i know, bad example, but still. It should, but apparently doesn't. From what I read in this thread xine and apparently also mplayer (an mplayer update tries to pull libpulse) are fine examples. This probably is due to incomplete 'libalsa pulse',

...

more than any other daemon to date. Upstream, rather than making Pulse Audio abstract itself like ESD or Phonon does, seems to want app developers to write their code SPECIFICALLY for Pulse Audio, which is NOT how its done. actually it is. mplayer, mpd, clementine <insert some audio software here>, all have native pulse audio backends. And those are normally used by people with small WMs, not gnome users. Not long ago Lennart urged developers not to use the PA API. That may have changed now, but I guess this is because people didn't listen and he was under pressure not to change the API. Anyway, if PA really worked

Excerpts from Rasmus Steinke's message of 2010-11-28 18:00:52 +0100: the part of PA that is supposed to imitate the alsa. that well and could emulate alsa and everything else as it should then why would the PA API be used at all? One PA to rule them all, One PA to find them, One PA to bring them all and in the darkness bind them

...

- An incredible array of utterly useless features (Like networking sound in a day and age where all PCs have sound systems they can use See above. I know several people (also on arch) that use pulse audio with mpd, since its the easiest way to control mpd remotely AND have sound locally.

On Mon, Nov 29, 2010 at 07:28:45AM +0800, Ng Oon-Ee wrote:

The ONLY major ALSA 'feature' which is not supported is memmap. Direct access to the sound-card's memory. Pulseaudio's devs are of the opinion that this cannot and should not be emulated, and that apps which use it are broken in design. I've not come across any latest-version-apps where this is still a problem, do you know of any?

While I would agree with anything else you wrote, if the comment quoted above refers to ALSA's mmap access mode it is wrong. All this mode has to do is provide the client application with pointers to read/write a period of samples from/to. The memory pointed to _may_ be directly mapped to a HW buffer, but there is nothing in the API that requires this - it could just be a user space memory buffer. ALSA itself provides mmap access to e.g. USB audio devices, this most certainly does not provide pointers to any USB hardware. Mmap mode can be emulated quite easily on top of another access mode (although it usually makes more sense to do things the other way round). There is nothing wrong with apps using this mode, and in fact many do, including Jack. Given that any driver will have either access to real HW buffers, or will create its own ones in memory, it's in fact the simplest and most direct way to get to the audio data. Ciao, -- FA There are three of them, and Alleline.

On Mon, Nov 29, 2010 at 10:31:06AM +0800, Ng Oon-Ee wrote:

Thanks fons, I was under the mmap alsa capability implied direct control over the hardware's memory.

It probably does in some cases (e.g. a hw: device on a PCI bus), but only to the sample data - there's no direct access to any control registers ever in ALSA. Since the access _could_ be to real HW it's of course ALSA that dictates the layout (separate buffers for each channel, or interleaved, or even more complex schemes) and the sample format (16/24/32 bit or float, LE or BE). The client application just has to accept this and do any conversions itself. Maybe the PA devs were thinking they had to emulate all of those, which could be a nightmare but is not necessary. They could just select the format that corresponds to any buffers they already have, and only support that one. Clients using mmap mode check what is available and adapt to it. Ciao, -- FA There are three of them, and Alleline.

On Mon, 29 Nov 2010 07:28:45 +0800 Ng Oon-Ee wrote:

...

- It's unstable. - It's got far too many unresolved bugs the upstream developers defer INCORRECTLY elsewhere simply because they can't be bothered to fix their software.

Where you've mentioned specific bugs below I'll answer. Otherwise this is just FUD generalization. And pulseaudio is not unstable just because an implementation in ANOTHER distro YEARS ago caused some problems.

What Yaro said was not a generalization, or even FUD. It was intended to be a statement of opinion, based on scientific theory of "If A works, and B doesn't, B must have problems" Plus, look at all the Ubuntu and RedHat folks who ask "How, How do I remove this beast of a pile from my system?"

...

- It wastes a lot of RAM. - It wastes a lot of CPU. - It causes noticeable audio latency.

RAM and CPU usage never appear on top 5 on my system. Its at 2% of CPU and 0.3% of RAM (4 GB) here on top. And synchronization of movie audio is perfect here (even when outputting at the same time to multiple sound cards, including a BT headset, try that with alsa)

Yeah, you aren't running on REALLY low end hardware. Try my box: a 700Mhz P3 Coppermine chip with 240MB of RAM open to the kernel. PA is a pile on that machine, and doesn't understand the ESS Maestro3i chip that's in it. ALSA when run through alsaconf... DOES! Start using REALLY low-end hardware and stop using flat top. As for multiple sound cards? Not a problem. I consistantly go between a USB headset and a full speaker system. How? Oh i don't know, by telling the app I want to talk to to talk to hw:1,0 instead of hw:0,0? Something like that. ALSA is a magificent Pile of steaming shit. Its just not as gold-covered as PA.

...

- It DOES NOT release sound to other daemons as your erroneously claim. It will not turn itself off for JACK just as it won't turn itself off for ESD or Phonon.

nedko (jack2) and the Pulseaudio devs specifically worked on such support. Just because you are ignorant of it does not make it not exist. As correctly pointed out though, jack2 is a separate implementation of jack from jack1, jack1 does not support notifying pulseaudio about its 'claim' on the soundcard. There's 2 players here, not just one.

That's a deeper, fundamental problem with the sound on Linux. Five different daemons do NOT need to be implemented just to do SOUND anymore. I think that's what Yaro is trying to get at.

...

- It actually doesn't support ALSA that well, it's ALSA module is stuck at 70% completion, with a lot of critical ALSA support stuck on that missing 30%. Again, further upstream blame gets laid on ALSA or drivers where it doesn't belong.

The ONLY major ALSA 'feature' which is not supported is memmap. Direct access to the sound-card's memory. Pulseaudio's devs are of the opinion that this cannot and should not be emulated, and that apps which use it are broken in design. I've not come across any latest-version-apps where this is still a problem, do you know of any?

You're going to go rally hardware vendors, right? What about my ESS Maestro3i? *the damn thing needs firmware* and its a *right bitch* to get working. Oh and did I mention on my other box the Realtek chipset needs to be told what it can output "Front" to? THis is a non-issue when it comes to comparing PA to ALSA. Blame vendors for being total shitheads. until then, there's a quite nice reason to emulate some hardware memmapping. As for apps that need it, I know a few. Quake, as well as some virtualization systems, really like having it because it makes their life Easier. SDLQuake relies on ALSA to do this, as well, and uses quite a bit of hardware memory because its CHEAPER. And ALSA has way more features not supported, for example this magical idea of "switches" -- You know, those things that fiddle bits in some keep-alive packet to the hardware that say "I want this to be like this". yes, I have to use switches.

...

- Even the Pulse Audio devs at one point admitted it breaks Linux audio.

Context, please. Quotation if possible. The only similar statement I remember is Lennart saying (more than a year ago) that it would break audio apps which rely on alsa hacks (most apps AT THE TIME). Which would mean that these apps need fixing.

You don't read through RH's bugtracker for PA do you?

If you think 'oh, what works before must be great code', I'm sure you'd be one of the first to protest (for example) Wayland on the grounds that X11 works just fine.

I'll protest Wayland because its Yet Another Thing To Change The World Coming Out Of RedHat. Oh, and that my computers don't all have full 3D glx acceleration. Really! they don't.

...

- A great deal of Linux applications have problems working with it, far more than any other daemon to date. Upstream, rather than making Pulse Audio abstract itself like ESD or Phonon does, seems to want app developers to write their code SPECIFICALLY for Pulse Audio, which is NOT how its done.

See above. You do not understand what is being done, nor have you made an attempt to. Pick up the latest Ubuntu liveCD, run it on almost any system you want. Sound will 'just work (tm)'. And they get all those nice features which they can CHOOSE to use or not. Your complaining is 2 years too late, because linux apps NOW support pulseaudio just fine. mplayer, vlc, mpd, wine, sdl, gstreamer et. al. The only sort of apps which still don't have good PA support are audio editing apps which are more meant for use with Jack (ardour and audacity for example).

Actually... the latest ubuntu (10.10) segfaults on 3 of my boxes. I haven't used Ubuntu since a futex() bug that they introduced would cause random lockups during Mutex interactions in single-threaded applications. Yes there's a case where you want to use a mutex in a single threaded application, primarily if you're using shared memory. I try playing Quake(2) on PA and I get laggy audio, poor performance (it brings my load up past 10!) and generally REALLY BAD results. PA brings when IDLING my load up to at least 2-3 when I'm on a P3 700Mhz coppermine chip. As someone who regularly calls most of the linux community the "Linux Children", I feel that its appropriate now. With each new Big Thing, its assumed you're using the best damn computer on the face of the planet. When FreeSWAN was doing its development, you know how they found memory leaks? they loaded it on a 200Mhz box with 8MB of ram. Memory leaks of BYTES each were found. As well, Pulse still doesn't work on my Alienware laptop. Realtek chipset, hda_intel picks it up as being generic. things almost work, except headphones. PA will only let sound go through the front speakers, while ALSA just has a switch. Its a known WONTFIX bug, too.

...

- An incredible array of utterly useless features (Like networking sound in a day and age where all PCs have sound systems they can use themselves. Never count on networking where an actual local system will do.) that Pulse Audio fans never use bt love to brag about so they can distract from Pulse Audio's obvious problems, just like you are doing right now.

Yes, you don't use a feature so its utterly useless. Good point! And its not like that's the ONLY feature available to pulseaudio.

Honestly, I think what he was trying to get at is there are much more UNIX-flavored ways to do this. ALSA, OSS, even at one point (And I know I'll get criticism for this) yiff-server[0] get this right. [0] http://packages.debian.org/source/squeeze/yiff -- Morgan Gangwere <0.fractalus@gmail.com> PUNY DISCLAIMER: I'm my own person. I make misteaks. Please, remember this. Debian to Arch convert. indrora on IRC.

On 29.11.2010 23:25, "Jérôme M. Berger" wrote:

Morgan Gangwere wrote:

...

As well, Pulse still doesn't work on my Alienware laptop. Realtek chipset, hda_intel picks it up as being generic. things almost work, except headphones. PA will only let sound go through the front speakers, while ALSA just has a switch. Its a known WONTFIX bug, too.

This bug is even worse for me: the only output that PA will recognize on my system is the HDMI output from my *video* card! I don't have any HDMI capable peripheral to even try to hear it! Alsa outputs to my true sound card without any problem...

Jerome

did you try manual driver loading? in /etc/pulse/default.pa: ### Load audio drivers statically (it's probably better to not load ### these drivers manually, but instead use module-hal-detect -- ### see below -- for doing this automatically) load-module module-alsa-sink load-module module-alsa-source device=hw:1,0 #load-module module-oss device="/dev/dsp" sink_name=output source_name=input #load-module module-oss-mmap device="/dev/dsp" sink_name=output source_name=input #load-module module-null-sink #load-module module-pipe-sink ### Automatically load driver modules depending on the hardware available #.ifexists module-udev-detect.so #load-module module-udev-detect #.else ### Alternatively use the static hardware detection module (for systems that ### lack udev support) #load-module module-detect #.endif

2010/11/29 "Jérôme M. Berger" :

Morgan Gangwere wrote:

...

As well, Pulse still doesn't work on my Alienware laptop. Realtek chipset, hda_intel picks it up as being generic. things almost work, except headphones. PA will only let sound go through the front speakers, while ALSA just has a switch. Its a known WONTFIX bug, too.

So most likely the driver needs to be fixed instead.

...

       This bug is even worse for me: the only output that PA will recognize on my system is the HDMI output from my *video* card! I don't have any HDMI capable peripheral to even try to hear it! Alsa outputs to my true sound card without any problem...

You could perhaps file a bug with PA. Or find help on the PA mailinglist. Cheers, Sander

On Tue, Nov 30, 2010 at 11:03 AM, Morgan Gangwere <0.fractalus@gmail.com> wrote:

On Mon, Nov 29, 2010 at 4:23 PM, Sander Jansen wrote:

...

So most likely the driver needs to be fixed instead.

its not even that -- realtek's driver for it is patched against some godforsakenly old version of ALSA.

So the driver is fixed, but not for the current alsa version? Seems like a ALSA problem to me.

...

...

...

       This bug is even worse for me: the only output that PA will recognize on my system is the HDMI output from my *video* card! I don't have any HDMI capable peripheral to even try to hear it! Alsa outputs to my true sound card without any problem...

You could perhaps file a bug with PA. Or find help on the PA mailinglist.

You'll get "Its ALSA's fault, not ours".

File a bug with ALSA (or find help on the ALSA mailinglist) then, so the driver works correctly pulseaudio. You act as if they're lying to you and they just want to blame ALSA for all their problems. I hardly doubt that is the case. I don't think complaining on the General Discussion list of Arch Linux will get you anywhere. Cheers, Sander -- "The sands of time were eroded by The river of constant change."

On Tue, 2010-11-30 at 20:41 +0100, "Jérôme M. Berger" wrote:

Sander Jansen wrote:

...

2010/11/29 "Jérôme M. Berger" :

...

This bug is even worse for me: the only output that PA will recognize on my system is the HDMI output from my *video* card! I don't have any HDMI capable peripheral to even try to hear it! Alsa outputs to my true sound card without any problem...

You could perhaps file a bug with PA. Or find help on the PA mailinglist.

I did (well actually, *I* didn't: I went to look and saw that someone else had already asked). The answer was: "Who is stupid enough to have more than one sound card anyway?"

Jerome Source please. I (and quite a few others on the PA list) have multiple sound cards, and I've never encountered such attitudes from the primary developers. The whole point of pavucontrol and module-combine is to allow for easy sending of signals to different or multiple cards/outputs.