[LAD] Guide to Linux Sound APIs

[Lennart Poettering]

On Tue, 30.09.08 11:19, Gene Heskett (gene.heskett at verizon.net) wrote:

> >> we're battling with M$, a generally futile endeavor, and that is
> >> gonna lead to a lot of profanity & name calling.  This is after
> >> all, linux, where choice is a talking point.
> >
> >Hi Gene, I think that the complaint should be aimed at distributions,
> >really. If they choose to ship foo they should make sure it works.
> >Which they tend to do to some (large) extent.
> >
> In the case of Fedora, no, the buck stops there, and I'm made to be the 
> bad-ass.  It looks to me as if they are deliberately shielding the 
> developers, or maybe they are locked in a closet off the lunch room living on 
> scraps?

This is utter nonsense.

There are probably no companies that are more open about what their
developers do than Red Hat. Most of us have blogs where it is very
simple to follow what we do. And most of the time they are syndicated
all around the net. Almost all our development happens upstream and
can be followed in git repos and stuff. We attend conferences where we
explain what is going on -- and a lot of them. I post regularly on
mailing lists like this one. We hang around on IRC almost our entire
work time.

If you call us shielded off then I wonder what you'd call everyone
else.

> I dunno.  What I did come away with was that I was on my own, and that PA 
> simply ignored the 8 line stanza in my modprobe.conf that makes it all Just 
> Work when PA is prevented from screwing with things.

ALSA device indexes are not stable anymore, they depend on the driver
initialization order during boot time which is not deterministic
anymore, since this happens in parallel now. That's why PA ignores
them and uses HAL UDIs for identifying audio devices instead. (I
assume that you are referring to the device indexes when you talk
about modprobe.conf).

> Without any meaningful docs on how to go about configuring it, if indeed it is 
> configurable, the easiest thing to do is remove as much of it as possible 
> without nukeing kde itself.

There are quite a bit of docs out there. Just check out
http://pulseaudio.org/wiki/Documentation.

> >In the past all of us had to realize that the minute we wanted to
> >deviate from what a distribution considered to be a "standard system"
> >(like in your case 2 sound devices) we were pretty much on our own.
> 
> Yes, that is a given.  But in order to do this intelligently, there must be 
> docs of the 'this does that effect' in existence.  Apparently there are none 
> or URL's would have been offered.

How would you like to have them offered? Maybe home delivered as printed
books? Would that suit you?

Have you ever tried to go to "pulseaudio.org" if you had a question?
Have you ever tried this thing called "Google"? It's a so called
"search engine" that helps you find things when you don't know where
to look. It's pretty hot stuff!

> >So I think there is a huge demand for more and better integration on
> >the distribution side, for user tools to make not-so-standard stuff
> >just work as well. Which is A Lot Of Work, right? We'll get there,
> >slowly, I'm sure.
> >
> Probably, and at about the same pace as NM moves, which is glacial.  Dumbassed 
> typo's fixing takes a year to make it from patch submission to distro 
> included.  That, when it effects 90% of the users, should be a week.  Max.

Assuming that you mean NetworkManager by "NM": you are underestimating
how much integration work this actually is. The kernel-userspace
interfaces for networking have been total chaos in the past. And it is
getting better. Much better.

And in the end: stop complaining! If you think we are incompetent
morons, then scratch your own itches and give something back for all
the apparently crappy stuff we happily give to you for free.

Thanks,

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4