On Sat, 2012-08-11 at 13:05 +0800, Oon-Ee Ng wrote:
> On 11 Aug 2012 08:14, "Ralf Mardorf" <ralf.mardorf@alice-dsl.net> wrote:
> >> But using dummy packages is just cheating.
> >
> >
> > So I should do audio productions with a Linux, that is unable to use my
> audio card? How should I do this?
> >
> > Regards,
> > Ralf
>
> By installing a distro that doesn't force you to use pulseaudio. Oh wait,
> that's Arch.

And whats bad with building a dummy package, if I wish to use packages
with pulseaudio dependencies?

On Sat, 2012-08-11 at 09:45 +0200, Jelle van der Waa wrote:
> Have you ever tried to report your problems with PA and your soundcard
> to upstream?

Have you ever really read what people wrote and why we are against it?

Regards,
Ralf

On 11 Aug 2012 18:53, "Ralf Mardorf" <ralf.mardorf@alice-dsl.net> wrote:
> On Sat, 2012-08-11 at 09:45 +0200, Jelle van der Waa wrote:
> > Have you ever tried to report your problems with PA and your soundcard
> > to upstream?
>
> Have you ever really read what people wrote and why we are against it?
>
> Regards,
> Ralf
>
And you're dissatisfied that the Envy chipset isn't supported, even though
the project's stated goal is desktop users (translation stereo only). You
may disagree with that goal and their definition, but the traditional
solution to that is to get coding. Complaining doesn't change anyone's
minds, especially when you use hyperbole (most users etc)

Am Sat, 11 Aug 2012 09:45:34 +0200
schrieb Jelle van der Waa <jelle@vdwaa.nl>:

> Have you ever tried to report your problems with PA and your soundcard
> to upstream?

How many times does it have to be said, that there are bug reports filed
to upstream which have been ignored by upstream resp. which have been
closed as fixed by first blaming ALSA for the PA problems, even if ALSA
supports those cards perfectly out-of-the-box since years, then writing
an obscure ALSA configuration which cripples those cards to simple
stereo cards and now, after many discussions like this one, they
suddenly say that PA is only meant for desktop purposes and not for
professional purposes?

How often does this have to be mentioned?

Heiko

On Sat, 2012-08-11 at 19:14 +0800, Oon-Ee Ng wrote:
> On 11 Aug 2012 18:53, "Ralf Mardorf" <ralf.mardorf@alice-dsl.net> wrote:
> > On Sat, 2012-08-11 at 09:45 +0200, Jelle van der Waa wrote:
> > > Have you ever tried to report your problems with PA and your soundcard
> > > to upstream?
> >
> > Have you ever really read what people wrote and why we are against it?
> >
> > Regards,
> > Ralf
> >
> And you're dissatisfied that the Envy chipset isn't supported, even though
> the project's stated goal is desktop users (translation stereo only).

Personally I don't care for the Envy24 chip, since my audio card for
sure has a much better hardware mixer. It's just that Envy24 cards are
widespread, since those are cheap and they usually are better than
onboard devices and many are stereo only. My Envy24 cards are for MIDI
only.
On non-audio user mailing lists there are often requests regarding to
"no sound". In the end "most of the times" it's pulseaudio that breaks
audio for desktop users. Btw. do consumer nowadays not usually need 5.1
instead of stereo?

> You may disagree with that goal and their definition, but the traditional
> solution to that is to get coding.

Today still most coders are interested that they don't break something.
The coder we are talking about claims that the ALSA drivers are borked
and similar strange things, when users report issues. IMO it's the task
of this coder to rewrite the drivers, when those won't work with his
software, since the drivers do work without his software.

> Complaining doesn't change anyone's minds, especially when you use
> hyperbole (most users etc)

So most computer users do not use other operating systems? There are
several reasons for this, pulseaudio isn't the only reason, but it has
got much weight.

To shut up won't change the situation.

Btw. I'm not complaining only, I fix all my Linux installs and I help
other people to fix their installs. But when I say using a dummy package
will solve issues, than it's also not ok. Why don't ship distros with
dummy packages for pulseaudio? I never noticed that a dummy package did
break something, but even if it should break something, at least there
are more advantages for those who can't use pulseaudio, due to their
hardware.

Today users have the choice to use DEs that don't need pulseaudio, but
if we would be quiet, perhaps one DE after the other would make
pulseaudio a dependency.

Noise is part of how communities work. Silence would cause stagnation.

Words about "most people" of cause belong to my broken English, if you
like we could continue in German. I already said, that marginalized
groups are important.

However, I'll read what ever you'll write + I'll reflect deeply about
your words, but I guess I've nothing to add to this topic at the moment
myself.

Regards,
Ralf

On Sat, Aug 11, 2012 at 01:35:10PM +0200, Heiko Baums wrote:

> How many times does it have to be said, that there are bug reports filed
> to upstream which have been ignored by upstream resp. which have been
> closed as fixed by first blaming ALSA for the PA problems, even if ALSA
> supports those cards perfectly out-of-the-box since years, then writing
> an obscure ALSA configuration which cripples those cards to simple
> stereo cards and now, after many discussions like this one, they
> suddenly say that PA is only meant for desktop purposes and not for
> professional purposes?

All correct, and we'd better be happy about that. The problem
is *not* that PA doesn't support multichannel cards - it would
still be completely useless for any serious audio work and we
would still have to disable/bypass/remove it even if it would
support PRO hardware.

The problem is that it becomes more and more difficult to
install a system without all sorts of (for me and others)
useless components such as PA. The reason is lots of hard
dependencies that should be optional extensions instead.
When L.P. claims e.g. that Gnome wants 'usability' and
'accessibility', therefore it needs and audio stack and
since the best one for desktop use is PA (no discussion)
it pulls in PA, that does make sense. But when it becomes
impossible (using binary packages) to install Gnome without
PA (while accepting the consequences) that just amounts to
*very bad design*. Because technically there is *no reason*
why things should be that way. If Gnome doesn't find the
PA components it needs for certain non-essential funcions,
it should just go on without them.

The same goes for consolekit, polkit and whatever other
kids the family has grown meanwhile. They do not provide
essential functionality, rather they interfere with the
normal way to contoll access etc., so they must remain
optional.

Now udev has been merged with systemd, and one can wonder
why. According to the authors, it is 'because they share
some common code'. A rather weak argument, that would be
true for almost any two subsystems you can imagine.

Udev is perfectly usable and useful on its own, it should
never be merged with something else that should remain
optional. But maybe that's what behind it - in the long
term systemd is supposed not be optional. So what will
be merged in next ? The kits ? Dbus ? Filesystems ?
Networking ? It will end up to be one giant 'system' blob,
take it or leave it, as we know from other platforms, with
no choice at all for the user.

L.P.'s reply to concerns like this (if systematically
interrupting a speaker during his presentation can be
called 'replying') is 'what are you whining about, it's
all free, it's all open, submit a patch'. As if something
like systematic bad design and creation of dependencies
could be mended with a patch.


Ciao,

--
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

On Sat, Aug 11, 2012 at 2:48 PM, Fons Adriaensen <fons@linuxaudio.org> wrote:
> The problem is that it becomes more and more difficult to
> install a system without all sorts of (for me and others)
> useless components such as PA. The reason is lots of hard
> dependencies that should be optional extensions instead.
> When L.P. claims e.g. that Gnome wants 'usability' and
> 'accessibility', therefore it needs and audio stack and
> since the best one for desktop use is PA (no discussion)
> it pulls in PA, that does make sense. But when it becomes
> impossible (using binary packages) to install Gnome without
> PA (while accepting the consequences) that just amounts to
> *very bad design*. Because technically there is *no reason*
> why things should be that way. If Gnome doesn't find the
> PA components it needs for certain non-essential funcions,
> it should just go on without them.
>
> The same goes for consolekit, polkit and whatever other
> kids the family has grown meanwhile. They do not provide
> essential functionality, rather they interfere with the
> normal way to contoll access etc., so they must remain
> optional.

For better or worse, the reality is that there are hard dependencies
on things you don't like. It seems that upstream is unwilling to
change that. Rather than just complain about it (which will not change
anything), why don't you try to find out what upstream would be
willing to do to serve your usecase? I know for instance that
pulseaudio should be able to disable itself if it finds jackd running
(as PA acknowledges that it does not serve the same usecases as jack).
Maybe that is not exactly what you need, but perhaps you could request
some similar functionality. If you do it in a nice and constructive
way based on technical arguments, I'm sure it would be merged.

> Now udev has been merged with systemd, and one can wonder
> why. According to the authors, it is 'because they share
> some common code'. A rather weak argument, that would be
> true for almost any two subsystems you can imagine.

This is a misrepresentation. Udev and systemd were merged I think
mainly because they "belong together", but also because they had
cyclic build dependencies as they are very tightly integrated. It is
not the case that systemd swallows anything it shares code with, in
fact some stuff is being pushed into util-linux away from systemd.

> Udev is perfectly usable and useful on its own, it should
> never be merged with something else that should remain
> optional. But maybe that's what behind it - in the long
> term systemd is supposed not be optional. So what will
> be merged in next ? The kits ? Dbus ? Filesystems ?
> Networking ? It will end up to be one giant 'system' blob,
> take it or leave it, as we know from other platforms, with
> no choice at all for the user.

I think there is no interest (upstream) in trying to make systemd
optional forever, so this is a concern you are probably right about.
However, the suggestions of what might be merged show that you are
either joking or don't know these projects well. At some point parts
of dbus will move into the kernel (so that is something to troll about
I guess).

-t

On Sat, 2012-08-11 at 15:30 +0200, Tom Gundersen wrote:
> I know for instance that pulseaudio should be able to disable itself
> if it finds jackd running

No sarcasm, I seriously want to know about this.

I only know that this is possible with jackdbus. Can you provide a link
or do you mean jackdbus too?

Regards,
Ralf

On 08/11/2012 09:30 AM, Tom Gundersen wrote:

[putolin]

I think there is no interest (upstream) in trying to make systemd
optional forever, so this is a concern you are probably right about.
However, the suggestions of what might be merged show that you are
either joking or don't know these projects well. At some point parts
of dbus will move into the kernel (so that is something to troll about
I guess). -t


One thing that the folks/upstream that are merging all these things
together is missing is that the future of "user" computer is moving to
phones and ipad type devices. PC will still be around but the consumer
has spoken and it looks like he/she is moving to these devices. I don't
condemn them for doing so as they want something that works. Turn it on
and get what they want done, PCs don't do this.
How are/would these giant concoctions going to play here as they don't
have the storage, memory, or cpu to handle this. The direction should
be going in the tool kit style as in here's the kernel and you can bolt
on all of these independent things. Something like android?

On Sat, 11 Aug 2012 15:30:09 +0200
Tom Gundersen <teg@jklm.no> wrote:

> This is a misrepresentation. Udev and systemd were merged I think
> mainly because they "belong together", but also because they had
> cyclic build dependencies as they are very tightly integrated. It is
> not the case that systemd swallows anything it shares code with, in
> fact some stuff is being pushed into util-linux away from systemd.

I keep seeing this "quote" on the net, is it not accurate?

"Sievers explained that it will still be possible to install udev
independently of systemd. He added that this option will be supported
in the long term because separate builds are required to ensure that
initrds (initial ramdisks), which don't include systemd, work
correctly. Distributions that don't use systemd can continue to build
udev as before, but will have to use the systemd sources."

---

Joakim

On Sat, 11 Aug 2012 09:59:54 -0400
Baho Utot <baho-utot@columbus.rr.com> wrote:

> On 08/11/2012 09:30 AM, Tom Gundersen wrote:
>
> [putolin]
>
> > I think there is no interest (upstream) in trying to make systemd
> > optional forever, so this is a concern you are probably right about.
> > However, the suggestions of what might be merged show that you are
> > either joking or don't know these projects well. At some point parts
> > of dbus will move into the kernel (so that is something to troll about
> > I guess). -t
>
> One thing that the folks/upstream that are merging all these things
> together is missing is that the future of "user" computer is moving to
> phones and ipad type devices. PC will still be around but the consumer
> has spoken and it looks like he/she is moving to these devices. I don't
> condemn them for doing so as they want something that works. Turn it on
> and get what they want done, PCs don't do this.

Smartphones, tablets and i* devices are toys. Have you ever tried to compile
Android/openWebOS? Or openwrt for a router? Or even ArchlinuxARM? They is not
nearly as flexible as PCs. Sure, if all you need from a computer is a
means for posting crap on facebook, then consumers are right. Just because
these mobile/embedded devices are hyped doesn't mean they own the future.

Besides, systemd, PA, dbus are quite natural for embedded devices. For
instance, Palm has been using PA in their devices since first versions, and
quite successfully.

> How are/would these giant concoctions going to play here as they don't
> have the storage, memory, or cpu to handle this. The direction should
> be going in the tool kit style as in here's the kernel and you can bolt
> on all of these independent things. Something like android?
>
>

Mobile phones like samsung galaxies have dual core Cortex A10 (?) and LG
Tmobile GX (at least in the US) runs on quadcore Nvidia tegra. That's more
processing power than my previous laptop.

--
Leonid Isaev
GnuPG key: 0x164B5A6D
Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D