Jay Vaughan wrote:
look, the point is: your proposal is faulty. having
two logins, one
for 'pro' use, and one for 'my teenage daughter', instead of
engineering software subsystems that can accomodate the need for
professional, always-working, rock-solid stable audio .. this is just
.. stupid. plain and simple.
i'm not saying -you- are stupid, just your idea.
Hi Jay:
I lied about retiring from this discussion. ;-)
I went back and re-read jwz's comments, and I also re-read most of the
commentary in this thread.
I'm not sure how anyone can reasonably object to your (and jwz's)
assertion that things should "just work". Who *wouldn't* love it ?! But
as this thread demonstrates there seems to be more of a problem than is
at first apparent.
I agree that the distinction between pro and consumer should be a
non-issue. Historically hardware manufacturers certainly make the
distinction, they build some gear for Johnny Stay At Home and other gear
for Jimmy On The Road Touring. But I don't think the distinction works
so well when it comes to software at the level under discussion.
Ideally we'd be rid of artsd, esd, and all the legacy from OSS/Free.
We'd have one sound server (JACK?) and software mixing would be enabled
by default. The remaining question is how to make this mandatory for at
least the mainstream distros. Perhaps an appeal to the LSB ? I really
don't know how such decisions are made.
I do feel that despite the advances made in Linux audio development
the domain is still perceived as something of a weak sister. We have
less manufacturer support than any other hardware aspect of Linux, we
are probably one of the smallest development communities, and we have
inherited an unholy mess of conflicting audio subsystems (ALSA, OSS),
sound servers (artsd, esd, JACK), incomplete implementations (lack of
software mixing, poor system configuration process), and a dearth of
easily accessible and comprehensible documentation.
We've seen some amazing development progress, and I don't read any
disparagement of these advances in your messages. Am I correct to
consider you supportive of Linux audio development ? If I read you
correctly it seems you're arguing on these issues:
1) The Linux audio software world is currently too confusing for the
novice (or even the experienced user) to quickly and efficiently prepare
his system for use. It takes too long to install and configure a working
audio system, and the frustration is a real problem if Linux audio wants
more adherents.
2) The distros have no guidelines to follow regarding implementation
and realization of ALSA's features. This complication adds to the
frustration above, and new users should not have to wrestle with such
complications. These problems are exactly what the distros were intended
to remedy, but their lack of concern for anything more than the most
basic audio service screws the pooch for the user who discovers that he
loses his system sounds when listening to his MP3s.
Also, forgive my ignorance of OSX, but it seems that it's being held
up as the Holy Grail for the normal user. I have some very basic
questions regarding OSX and its audio system, perhaps you can tell me
what I'd like to know:
1) Is OSX open-source and free ?
2) Will OSX run on Intel hardware ?
3) Does OSX have the range of FOSS development tools as is available
for Linux ?
4) Is there *any* configuration required for the OSX audio system ?
I'll restrict my interest in all of this to only issues regarding
usability and transparency. Again, I don't see how anyone can logically
argue that installing and configuring Linux audio software deserves to
be the trial it is at this time. Ico Bukvic and Christoph Eckert have
devoted energy to discussing possible ways of mitigating this toil, but
I sense that getting the attention of The Ones Who Matter is no trivial
pursuit. I would love to see Linux audio working for everyone as nicely
as it does for me, but I know that it does so because I've been at it
for a good long while. There's just no good reason to expect other users
to have to make the same efforts, there is no special virtue in the
thing being difficult.
The point of it all is to get to making music as soon as possible,
without having to hassle with configuration details at any level. I
don't know if such an easy scenario is available to Windozers or OSX,
but it's certainly not the standard experience for a lot of (or most?)
Linux users. And if it *is* difficult on either of those other systems
that's certainly no good reason why it should be difficult for us too.
We can and should do better.
As advanced users we on this list already know how to make our systems
do what we want, but our experience is not being translated for the
normal user. I agree that the distros should start fixing things that
they ought to fix, including the transparent implementation of various
features of ALSA. jwz believes he shouldn't have to make any special
effort at getting Linux multimedia software working, and he's right,
period. Some good ideas have been presented in this discussion, but
no-one has indicated clearly *how* these ideas can be widely adopted.
SuSE is likely to show more advanced audio implementation because they
have members of the ALSA team working for them, but we shouldn't have to
point new users to specific distros just to have what normal users
expect from a contemporary working audio system. So who do we lobby at
Red Hat or Debian or Slackware or Mandriva or ...?
And on that topic: Why aren't the advances made by Planet CCRMA and
Demudi integrated into the standard distributions themselves ? Is it
really such a great thing to have to point new users to a specific
distribution just to get finely working audio ? If the distro
manufacturers and maintainers aren't aware of the possibilities already
available to them wrt audio, perhaps our community isn't working hard
enough to reach them ?
Just some rambling thoughts. I wish I had more time to spend on these
matters. Unfortunately it's a time-consuming task, worse than setting up
a Linux audio subsystem, and with probably even less satisfying results. ;-)
Best regards,
dp