how is pulseaudio supposed to work?

[Lennart Poettering]

On Wed, 19.12.07 11:44, Olivier Galibert (galibert at pobox.com) wrote:

> > That means, for now, you have to use the raw ALSA "spdif" device if
> > you want to playback audio on spdif. That hasn't changed from pre-PA times.
> 
> I can use alsa for everything, I know that already.  That was not the
> point of the email.
> 
> If your answer to "how can PA be used to support my configuration" is
> systematically "don't use PA", why are you working on PA in the first
> place?

Come on. The are a lot of thing PA doesn't do right now. Not just this
one. However, there happen to be a couple of things PA can do very
well.

What kind of stupid game is this, anyway? You find cases where PA
doesn't work without manual reconfigration. And then you ask me, and I
say, "yes, it doesn't work", and then you tell me "yes, i thought so,
PA is total crap." I you want we can play this game with swapped roles:
I find a feature that software you wrote doesn't do and then I
tell you "Your software sucks big time." It certainly would be a lot
more fun for me that way!

Also, in this case the bad support of SPDIF in PA is not really PA's
fault. It's more ALSA's since it doesn't really have any (working) API
for discovering if spdif is available and if it is exclusive to analog
out.

Also note, that PA supports spdif quite fine if you do manual
reconfiguration in style of adding a single line to /etc/pulse/default.pa:

  load-module module-alsa-sink device=spdif:0

Oh, and it is also not the case that I wouldn't be aware of the messy
SPDIF support right now, and that I wouldn't be working with the ALSA
people to find a resolution. 

> > You should be using the normal fast-user-switching for that.
> 
> So now gdm and using a panel is a fedora requirement for multiuser
> support?

We try our best to supply you with easy-to-use software for doing
f-u-s. And all you do is telling us is that you refuse to use our
software, but go on complaining that f-u-s doesn't work for you?

How do you think we should be fixing this? I mean, it's hard to get
this fixed for you if you don't want to use our code. Don't you think?

The f-u-s code is open. You're welcome to hack up your one UI for
it. That's what Free Software is all about: scracthing your own
itches. We already supply you with a couple of UIs, if they are not
good enough for you, then I guess you need to get your hands dirty
yourself and teach us fools how a really good UI should look
like.

> > PA supports f-u-s just fine, as I think I already wrote about 555
> > times on this thread.
> 
> Where fine means "only the currently selected user can do sound", from
> what you wrote too.  Which, if you had bothered to read my use case
> with your brain on, you'd have noticed is not fine at all.

Let's stop this stupid discussion now. I already wrote countless times
on this thread: with some minimal reconfiguration you can get PA
working for you, or can bypass it, whatever suits you best.

And I already explained in detail why we chose to do multi-session
support the way we are doing it. We tend to do our stuff for good reasons
the way we do. And we explain them to anyone who asks. And we take
suggestions. But in the end, the one who produces the code is ... the
one who produces the code.

Lennart

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