13 Nov
2008
13 Nov
'08
8:54 p.m.
On Fri, Nov 14, 2008 at 01:22:47AM +0100, Paul Davis wrote:
On Fri, 2008-11-14 at 01:08 +0100, Fons Adriaensen
wrote:
* If they are equivalent that makes sense. But how ofter are
they really ? This one surely isn't.
* If that can be done without adding layers of complexity
it makes sense. But that is apparently not the case.
My conclusion so far is that however low-level, unportable,
<insert your favourite negative attribute> a simple ioctl()
or equivalent may be, it seems in the end a lot easier to
use.
Please don't misunderstand my rant. I'm pretty much of the
opinion that the whole of ALSA is in a sense a masterpiece
of software engineering, of applying engineering principles
consistently and without compromise, and that is *not* meant
ironically. I'm not questioning the skills, motivation, effort,
and good intentions of its designers. But the result misses
the mark by a mile in any practical sense, and that is mainly
because the high level analysis apparently exists only in
the designer's heads. It must exist there - they couldn't have
written all of ALSA without it. If they had spend a fraction
of the time wasted to write useless documentation to explain
that, things would be different.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
Now if someone can point me to some existing docs
that
explain how I can e.g. set the sample clock source on a
RME MADI card in less than ten lines of C code (knowing
the parameter names, ranges, etc - no need to find them
out dynamically, I can read them asound.state) then I'll
eat my hat. It shouldn't be difficult. On some competing
systems all it takes is one ioctl().
i don't want to defend the lamentable state of the ALSA docs, but this
last shot was a bit cheap Fons. the idea behind the ALSA control API was
that equivalent controls on different cards would be controlled in the
same way.