Re: [OT] ALSA userspace API complexity

[Olivier Galibert <galibert@pobox.com>]

On Fri, Jan 06, 2006 at 01:22:48AM +0100, Joern Nettingsmeier wrote:
> agreed. nobody doubts this. a long time ago, this thread was about 
> removing obsolete *drivers*. that is orthogonal to the api issue.

Yeah, and there was way less flamage then too :-)


> then people starting whining about bugs in the alsa oss layer, while 
> being too lazy to file bug reports. nobody wants to "cripple" this api, 
> saying so is just stupid FUD and rather offensive.

You know, having the problem of device blocking between the oss api
kernel support (emulation is not a very good term in that context) and
the alsa api kernel support being meet by -EWONTFIX and "Don't use
OSS, use Alsa-lib, it's infinitely better" is somewhat offensive too.
You want me to file a bug report on that to see how far it's going to
go?


> then somebody started an api discussion, where *oss* was represented 
> quite fairly. it does have its nice sides. but to me it looks like most 
> of the people bashing *alsa* for its complexity have not understood the 
> problems it tries to (and does) solve.

The "the documentation is perfect, you just not have read it"
fanboyism after having needed 2 or 3 days using that same
documentation to write a simple dynamic sound streaming in an
application I'm doing grates a little.  Also, I notice that all my
comments about the numerous problms as seen in the windows world that
come with having a kernel api defined as a shared library have gone
beautifully ignored.


> shuffle 16 tracks of 24bit 48k audio in and out of the machine at a 
> latency where a professional drummer will not complain, with routing 
> options adequate for professional work, and then let's see how simple 
> your API is.

I've done 64-channel microphone array capture, source tracking,
beamforming, speaker id and feeding an ASR over a network of computers
with a rather low latency.  I wrote or participated in the complete
chain, from programming the capture dsp in assembly and debugging it
with a 'scope, writing the linux driver to get the data on the pci, or
writing the data transmission infrastructure.  And the API is still
simple enough that it is becoming a de facto standard for smart space
applications and the comments are of the order of "there still are
some bugs (indeed there is, no doubts about that), but it allowed us
to having things working rather easily and fast".

Is that enough audio-unchallenged for you?  Oh, it does video too.


> in audioland, you have all kinds of funky shit going on in the hardware, 
> and you can't say, no we don't support that, to inelegant, because then 
> your stuff just can't compete.

That's why you want a clean core and an extension mechanism, and add
the extensions in the core once they're general enough.  See OpenGL.


> hardware peculiarities cannot be abstracted away without sacrificing 
> efficiency, and this makes for a complicated api.

No, it doesn't.  Again, see OpenGL.  Audio hardware variability is
laughable compared to video hardware variability nowadays.

But you need to designed your API starting from what people want to
do, not from what the hardware does in detail.

  OG.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/