lkml.org 
[lkml]   [2006]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [OT] ALSA userspace API complexity
    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/

    \
     
     \ /
      Last update: 2006-01-06 02:33    [W:5.837 / U:0.080 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site