The case for the /usr merge [LWN.net]

The case for the /usr merge

Posted Jan 29, 2012 18:09 UTC (Sun) by mpr22 (subscriber, #60784)
In reply to: The case for the /usr merge by sbergman27
Parent article: The case for the /usr merge

My instinctive questions would be "How large a sample size is two audio chipsets?" (I have no particular feel for how many different audio chipsets exists) and "Which audio chipsets, and did you file a bug report or just go 'bah, poxy lennartware *uninstall*' and not bother?".

to post comments

The case for the /usr merge

Posted Jan 29, 2012 20:22 UTC (Sun) by sbergman27 (guest, #10767) [Link] (11 responses)

Since it was introduced in FC6 or F7 or whenever, my success rate with PA has been 0%. It can sometimes be made to mostly work with some futzing around. But why bother when it offers no advantage to just using ALSA?

Anyway, a Google search on:

pulseaudio "no sound"

brings up over a million hits.

It's been admitted in this very thread that PA tries to do things that have worked for Apple on its tightly controlled harware, but apparently don't work well in the freewheeling world of PC hardware. That was a fatal design in PA for its intended audience.

Vendors of sound hardware don't care if PA works or not. And with Linux having been stuck at ~1% of the desktop market for the last 10 years, that situation is not likely to change. Best to deal with sound hardware the way it *is* and not the way you'd like it to be.

ALSA FTW! The pragmatic approach is often the best.

-Steve

You've started it...

Posted Jan 29, 2012 21:34 UTC (Sun) by khim (subscriber, #9252) [Link] (6 responses)

Anyway, a Google search on:

pulseaudio "no sound"

brings up over a million hits.

Which looks like a disaster if you'll not compare it with similar search

alsa "no sound"

which returns over 50 millions results.

ALSA FTW! The pragmatic approach is often the best.

Right. And my pragmatic approach is to close all bugs where some kind of non-standard configuration is used as INVALID. This reduces amount of testing required - which is practical for me. Systems with uninstalled PulseAudio most definitely fit the bill as far as sound is involved.

You've started it...

Posted Jan 29, 2012 21:40 UTC (Sun) by nix (subscriber, #2304) [Link] (1 responses)

And my pragmatic approach is to close all bugs where some kind of non-standard configuration is used as INVALID.

Right. So in the end nobody but the developers can use the configuration options provided, because if they use them they can't report bugs or get them fixed. And then those configuration options get removed because they're unused. And then we look around at the non-configurable desert which our free platform has become and wonder when exactly we took this wrong turn.

You've started it...

Posted Jan 30, 2012 9:56 UTC (Mon) by khim (subscriber, #9252) [Link]

Why do you think someone took the wrong turn? Non-configurable desert is one description which tries to imply this is somehow bad. Uniform experience is another description for the same thing - and it's usually praised by reviewers... unless they themselves want to change something - and can not.

I'm not saying all options are worthless (it'll be hypocritical for me to say so since I toggle quite a few knobs on new systems). But they should all earn the right to live. No exceptions. You must compare overhead the developer faces for given option with popularity of said option. If option is wildly popular then it must be supported even if it's quite painful for the developer. If it's trivial and does not require a lot of Q&A resources then it can be kept even if it's not all that popular. But if it's both not popular and painful - then it's better to make it go away.

You've started it...

Posted Jan 29, 2012 22:05 UTC (Sun) by sbergman27 (guest, #10767) [Link] (3 responses)

"""
Which looks like a disaster if you'll not compare it with similar search

alsa "no sound"

which returns over 50 millions results.
"""

44 million. But since PA depends upon the underlying sound system, if one's chances of getting sound working in Linux without PA are bad, their chances of getting it working with PA are far worse.

PA is the first time in the history of Linux that after the actual sound driver is working, the user still faces a major and long-standing hurdle in getting the sound server working. Sometimes I think desktop Linux has a deathwish. No, that's not right. At this point, in 2012, it's pretty certain that Desktop Linux has always had a deathwish. We never had a chance. We only kill the things we love.

You've started it...

Posted Jan 30, 2012 9:49 UTC (Mon) by khim (subscriber, #9252) [Link] (2 responses)

PA is the first time in the history of Linux that after the actual sound driver is working, the user still faces a major and long-standing hurdle in getting the sound server working. Sometimes I think desktop Linux has a deathwish.

Sorry, but you are wrong again. Try the aforementioned search with esd instead of pulseaudio or alsa - and you'll get more results then in pulseaudio case.

The fact that you personally know how to debug and fix problems with esd and don't know how to do the same with pulseaudio says more about you then about pulseaudio or esd.

You've started it...

Posted Jan 30, 2012 14:48 UTC (Mon) by raven667 (subscriber, #5198) [Link]

Even better than ESD, remember ARtS? Why have one sound server when you have have two incompatible ones both vying for access to a single, exclusive, sound output along with applications who try to use the sound output directly. Having one sound server rather than a bunch of incompatible ones fall in an out of fashion every few years is an improvement in and of itself, even if it was no better, which it is.

You've started it...

Posted Jan 30, 2012 19:48 UTC (Mon) by sbergman27 (guest, #10767) [Link]

"The fact that you personally know how to debug and fix problems with esd and don't know how to do the same with pulseaudio says more about you then about pulseaudio or esd."

I only use a sound server when such functionality is useful. i.e. network transparency. (Though HelloWorld has mentioned another feature useful for some.)

You don't seem to understand that the sound server is dependent upon the underlying sound system on either the client or the server machine.

I've had less trouble (in fact, no trouble) with ESD. But I don't use any sound server when none is required.

The case for the /usr merge

Posted Jan 29, 2012 21:43 UTC (Sun) by elanthis (guest, #6227) [Link] (1 responses)

> Since it was introduced in FC6 or F7 or whenever, my success rate with PA has been 0%. It can sometimes be made to mostly work with some futzing around. But why bother when it offers no advantage to just using ALSA?

My success rate has been 100%. ESD constantly crashed on me, and ALSA dmix has locked up on me before. Also, ALSA/ESD don't support device hot plugging with automatic output switching, which I do use here and there on my laptop.

Anecdotes are a GREAT way to debate!</sarcasm>

The case for the /usr merge

Posted Jan 29, 2012 22:50 UTC (Sun) by sbergman27 (guest, #10767) [Link]

"""
My success rate has been 100%. ESD constantly crashed on me, and ALSA dmix has locked up on me before.
"""

Obviously, that was a problem with your configuration or harware.

(That's a little joke. But do try the latest ESD nightlies! They're fantastic!)

I quite agree with you about anecdotal evidence. Unfortunately, it's pretty much all we have in Desktop Linux. Rightly or wrongly, one's own anecdotes take priority over others' anecdotes. And there is some justification for that. About all we can do right now is keep careful notes and do the best we can with the information we have, trying to keep in mind the 'p' significance of our own personal datasets.

It would be much nicer to have actual data. But indeed, the plural of "anecdote" is not "data".

On my machines, and my customers' machines, over the last serval years, PA has been pretty much a failure.

The case for the /usr merge

Posted Jan 30, 2012 2:07 UTC (Mon) by HelloWorld (guest, #56129) [Link] (1 responses)

> But why bother when it offers no advantage to just using ALSA?
It does offer advantages, for example the ability to move audio streams from one device to another (*very* handy with USB or Bluetooth headsets). Anyway, you're obviously biased against PulseAudio, so discussing this with you is probably a waste of time.

The case for the /usr merge

Posted Jan 30, 2012 7:48 UTC (Mon) by sbergman27 (guest, #10767) [Link]

"""
It does offer advantages, for example the ability to move audio streams from one device to another (*very* handy with USB or Bluetooth headsets).
"""

That's a reasonable enough point. It's not one that interests me. But it is likely significant to others. I would have nothing against PA if it did not so often break sound completely. If it sometimes allows people to enjoy a degree of increased flexibility, I would not begrudge them that.

-Steve