Re: [LAD] alsa and OSS (again?)

On Mon, Jan 21, 2008 at 10:04:54PM -0500, Paul Davis wrote:

> ALSA is going to vanish as an API for all but those developers who don't
> know how to use google. Pulse even has plans to "replace" JACK one day,
> but its lead author fully understands the challenge there.

The only parts that will remain are probably the hw:
devices, which generally work well and provide the
low-level access that you need to build things like
JACK on.

The _technical_ reasons why dmix/dsnoop apparently
can't be made to work as expected remain a mystery
to me. It's not because 'this can't be done in user
space' as has been said IIRC on the OSS author's
blog. JACK does it in user space.

Maybe the project has fallen victim to it's own
ambitions of providing all sorts of everything to
everyone - a range of access methods (mmapped,
blocking, non-blocking, callback,...), and the
whole collection of soft devices it can create
to keep everybody happy. I guess that in the
end the number of possible combinations just
exploded and became to large to handle.

Organising things this way was IMHO a bad idea.
Instead of trying to anticipate each and every
type of device an application writer would ever
want to talk to, it seems safer to provide just
a single interface, which should be close to the
hardware, and then a number of libraries (instead
of the preconfigured soft devices) to help
applications to convert to whatever they want,
providing things like e.g. sample rate conversion,
easier non time-critical access, etc.

Also, if the audio hardware has to be shared,
then no single app that just happens to produce
some sounds should _ever_ have been allowed to
think it could configure the hardware, to select
sample rates or formats. Just as normal apps
are not expecting to be able to format a disk,
or to configure the network interfaces. Part of
the blame is with the authors who insisted on
being able to do such things, even if the primary
function of their app was not related to audio at
all, just because it was easier.

There are other problems of course, one of them
being documentation about the *design* of the
system, not just the API. I once tried to debug
an ALSA driver, but had to abandon the exercise.
Almost everything in the drivers seems to be
done by callbacks and endless levels of indirect
calls via function pointers that are initialised
in dark places, and that makes it very difficult
to understand what's happening, and where.
The only way out (or in, for a driver developer)
is system design documentation, which is non-
existing AFAIK.

I haven't looked at OSS for a long time, not
since the first ever LAC presentation I heared
was the one by Takashi, on ALSA. But I will
look at it again, even if for most of my work
it's not really relevant - JACK rules.

Caio,

-- 
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev