Re: [linux-audio-dev] Re: What Parts of Linux Audio Simply Work Great?

> I lied about retiring from this discussion. ;-)
>

well .. good, because i believe this thread bears fruit.

> 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.
>

yeah, for phantom-powered XLR jacks versus 3.5mm mini-DIN's, sure.
its hardware.

but we're trying to discuss how to fix Linux audio, here. a software
problem, plain and simple. there need be no artificial lines drawn
in the sand between where we are now, and "It Just Works".

> 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 think the biggest problem right now is that there are soooo many
datapoints to accomodate. what would be great is if we could
formulate a survey of all the major distributions, what they are
doing for sound, and what apps they have included, and what they use.

some sort of collated data that gives us an ideal picture of the
existing scene.

personally, if i knew it would help, i wouldn't mind spending time
patching existing apps and submitting patches to their coders, if it
brought everyone into a 'common base' that could be further exploited
to put linux audio in a better state.

> 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.

all it takes is for us to make a concerted effort at solving the
situation, get *one* distro leader to get behind the effort and add
our solution to their next release, and it'll snowball from there. i
don't actually agree that its going to be 'so hard' to fix linux
audio.

> 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:
>

i am -very- interested in seeing linux audio improve to the point
where the scene is turned around, and we get new progress made on the
PR fronts about linux audio.

i think the hard work done by the core linux audio developers is far,
far, far, under-appreciated for the advances made; certainly Jack and
Ardour and co., are a formidable base to work from.

but the fact is: it -is- a mess.

> 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.
>

there are just too many options, some work, some don't, some work
with others, some don't. and, worse, its very difficult to educate
oneself on the options without getting pretty confused over -why-
things are the way they are.

> 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.

yeah, and to be fair, i honestly don't think that distro's are the
arena to solve this problem, yet. distro's simply package whats
there, get it working for their architecture ideology, and leave it
at that.

its the coders who do the actual hard work who will have to start this effort.

and i view efforts like PlanetCCRMA as a 'bridge' between these two
worlds, a project with a foot in both boats. we should exploit the
progress made on this to figure out how to simplify the problem.

> 1) Is OSX open-source and free ?
>

Darwin, the kernel which OSX depends on, is free.

> 2) Will OSX run on Intel hardware ?

Yes.

> 3) Does OSX have the range of FOSS development tools as is
>available for Linux ?

Yes. All F/OSS dev tools which work on Linux, can be used on OSX.
this is, in fact, one of the biggest threats to Linux (in my opinion)
once Apple have transitioned to x86: all 'our' goodies are theirs
too, only they've done all the really hard work already and made the
system usable to grandma while profiting from their hardware sales.

> 4) Is there *any* configuration required for the OSX audio system ?

device drivers, for the most part, do need to be installed with
specialized hardware, but from the beginning, whatever your
Apple-running-OSX machine ships with, will work, absolutely, from the
get-go.

I had to install drivers for my Presonus FirePod ('pro' firewire
audio interface), but this was braindead and simple, thanks to
Apples' Package manager scheme.

In OSX, drivers for hardware can be either: a) a kernel extension
(OSX' loadable modules), or b) a user-space driver that the kernel
can delegate work to as needed.

the choice is up to the developer of the hardware of course, but
having either/or options makes it very easy to support OSX.

>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 ...?

honestly, i don't think this is a distro problem, i think its a
"Linux Audio Software Developers" problem, and as a group we ought to
present the ideal solution, and convince the distro vendors to adopt
it, because it works.

> 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?

nope, it blows. I have, personally, avoided getting involved in
PlanetCCRMA, even though it is a very valid and worthwhile effort,
because it is far too distribution-dependent.

>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 ?

its too confusing, as it stands right now. we need a big, overall
picture of the scene:

1. What Audio Apps are out there that people like to/want to use easily?
2. What Audio API's do these Apps use?
3. What Audio API's are out there?
4. How do these API's expect to gain access to audio hardware?
5. What are the different means by which Audio hardware are presented to API's?
6. What platforms are these apps expected to run on? (remember: not just Linux)

.. a big chart with answers to these questions would help us see
where the distribution problems lay. More than likely, we'll find
some cross-over between 3/4/5, and this cross-over may point us
towards a solution. if there are API's that are demonstrably,
proven, to be great performers (portaudio? SDL_sound?) and some Apps
which seem adaptable to the 'greater solution' easily enough, then it
points to some 'boring patch work' from us peripheral LAD'ers that
could result in a smoother setup in general, and a greater selection
of audio apps capable of dealing with the answers to #5.

> 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. ;-)

i think this dicussion has borne a lot of fruit, personally. we
ought to build this 'big Audio App chart', though, to give us a
better view of the current scene.

anyone see my point? what else could we answer, by simply collating
the facts of the audio apps, following through to the driver level,
and what else should this chart show?

-- 
;
Jay Vaughan