Excerpts from Ng Oon-Ee's message of 2010-11-28 17:19:11 +0100:
>
> I'll take both your words on it. Its worth noting that Pulseaudio
> automatically corks when JACK wants a sound-device (jack2 that is, not
> jack1). Running phonon atop pulseaudio wouldn't make sense if every app
> uses phonon. Due to other considerations (for example that all the major
> distros are pushing pulse), this may not be the case in the future.

Just to make sure no-one gets wrong ideas: jack2, despite its name,
isn't going to replace jack. It's another implementation, not a
replacement. Both have their share of benefits and drawbacks, and
Jack (1) is the most used implementation.

Excerpts from Rasmus Steinke's message of 2010-11-28 18:00:52 +0100:
> 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',
the part of PA that is supposed to imitate the alsa.
> > 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
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 Sun, 2010-11-28 at 10:38 -0600, Yaro Kasear wrote:
> On Mon, 2010-11-29 at 00:27 +0800, Ng Oon-Ee wrote:
>
> GNOME 3 isn't even released yet. There's no CURRENT dependency in Arch,
> in [extra], for Pulse Audio.

Others have explained this to you already.
>
> 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.

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.

> - 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)

> - 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.

> - 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?

> - 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.

Necessity is a weird thing that seems to you to imply "what I need".
Sorry, you're not Linux Audio. Even a cursory glance through this thread
should indicate to you that there ARE people who need it for something
or other. Not 'just' networked audio as you imply. Routing between
multiple sound cards, good and automatic BT headset support, per-volume
app control. Yep, ESD and phonon have all that.

> - 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.

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.

> - 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).

> - 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.

> - 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.

Obviously you have not been keeping track of how Arch handles this. If
something is coming, the devs make a collective decision to incorporate
it as soon as possible without breaking things. See python3. Pulseaudio
has already been delayed much longer than anything else, partially
because of FUD from folks like yourself. The other reason as I
understand is that JGC is simply too overworked with his thousands of
packages to bother prior to this to figure out how to integrate
pulseaudio PROPERLY. Which he has now done, and in a way such that
without his announcement email you would not have noticed it at all.
Since you're basing complaints on past problems and not any CURRENT
problem with your Arch system.

Pulseaudio did expose a lot of bugs in alsa that needed to be fixed in alsa.
IIRC they are attempting to move from scheduling sound with the soundcard's
hardware interrupts to an entirely cpu based method. I can't remember
exactly what the technique is, but it allows for better latency control,
better mixing of applications which make different buffer size/latency
demands, and consumed less power overall because of
increased flexibility over have the processor sleep.

Pulseaudio has been buggy because in many cases they have been the very
first people to ever make use of some of the more esoteric parts of alsa.
Those parts also lacked proper documentation and many drivers didn't even
bother with a proper implementation.

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 Sun, Nov 28, 2010 at 06:44:10PM -0500, Simon Gomizelj wrote:

> Pulseaudio has been buggy because in many cases they have been the very
> first people to ever make use of some of the more esoteric parts of alsa.
> Those parts also lacked proper documentation and many drivers didn't even
> bother with a proper implementation.

True. And what PA probably needs most and ALSA does not provide
is a way to provide *lots* of buffering (more than a second, in
cases where latency does not matter), while at the same time
allowing an app to 'review' or 'rewind' this buffering in order
to ensure responsiveness to user commands (such as stop/play for
a player).

Ciao,

--
FA

There are three of them, and Alleline.

On Mon, 2010-11-29 at 01:15 +0100, fons@kokkinizita.net wrote:
> On Sun, Nov 28, 2010 at 06:44:10PM -0500, Simon Gomizelj wrote:
>
> > Pulseaudio has been buggy because in many cases they have been the very
> > first people to ever make use of some of the more esoteric parts of alsa.
> > Those parts also lacked proper documentation and many drivers didn't even
> > bother with a proper implementation.
>
> True. And what PA probably needs most and ALSA does not provide
> is a way to provide *lots* of buffering (more than a second, in
> cases where latency does not matter), while at the same time
> allowing an app to 'review' or 'rewind' this buffering in order
> to ensure responsiveness to user commands (such as stop/play for
> a player).
>
> Ciao,
>

I'm sorry, but did no one notice that I haven't said anything more and
have, in fact, dropped this discussion? Who are you arguing with?

On Nov 28, 2010, at 6:30 PM, Yaro Kasear <yaro@marupa.net> wrote:

> On Mon, 2010-11-29 at 01:15 +0100, fons@kokkinizita.net wrote:
>> On Sun, Nov 28, 2010 at 06:44:10PM -0500, Simon Gomizelj wrote:
>>
>>> Pulseaudio has been buggy because in many cases they have been the
>>> very
>>> first people to ever make use of some of the more esoteric parts
>>> of alsa.
>>> Those parts also lacked proper documentation and many drivers
>>> didn't even
>>> bother with a proper implementation.
>>
>> True. And what PA probably needs most and ALSA does not provide
>> is a way to provide *lots* of buffering (more than a second, in
>> cases where latency does not matter), while at the same time
>> allowing an app to 'review' or 'rewind' this buffering in order
>> to ensure responsiveness to user commands (such as stop/play for
>> a player).
>>
>> Ciao,
>>
>
> I'm sorry, but did no one notice that I haven't said anything more and
> have, in fact, dropped this discussion? Who are you arguing with?

Unfortunately it usually takes 10-100x informed responses to negate
each FUD riddled one.

I would just continue to stand by and absorb the yummy brownies of
information.

C Anthony [mobile]

On Sun, Nov 28, 2010 at 06:29:56PM -0600, Yaro Kasear wrote:
> On Mon, 2010-11-29 at 01:15 +0100, fons@kokkinizita.net wrote:
> > On Sun, Nov 28, 2010 at 06:44:10PM -0500, Simon Gomizelj wrote:
> >
> > > Pulseaudio has been buggy because in many cases they have been the very
> > > first people to ever make use of some of the more esoteric parts of alsa.
> > > Those parts also lacked proper documentation and many drivers didn't even
> > > bother with a proper implementation.
> >
> > True. And what PA probably needs most and ALSA does not provide
> > is a way to provide *lots* of buffering (more than a second, in
> > cases where latency does not matter), while at the same time
> > allowing an app to 'review' or 'rewind' this buffering in order
> > to ensure responsiveness to user commands (such as stop/play for
> > a player).
> >
> > Ciao,
> >
>
> I'm sorry, but did no one notice that I haven't said anything more and
> have, in fact, dropped this discussion? Who are you arguing with?

I did not respond to you but to Simon Gomizelj's message,
and I am not arguing at all.

Ciao,

--
FA

There are three of them, and Alleline.

On Mon, 29 Nov 2010 07:28:45 +0800
Ng Oon-Ee <ngoonee@gmail.com> 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.