lkml.org 
[lkml]   [2006]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [OT] ALSA userspace API complexity
    Date
    On Wednesday 04 January 2006 11:35, Jaroslav Kysela wrote:
    > On Wed, 4 Jan 2006, Pete Zaitcev wrote:
    > > On Wed, 4 Jan 2006 09:37:55 +0000, Alistair John Strachan
    <s0348365@sms.ed.ac.uk> wrote:
    > > > > 2) ALSA API is to complicated: most applications opens single sound
    > > > > stream.
    > > >
    > > > FUD and nonsense. []
    > > > http://devzero.co.uk/~alistair/alsa/
    > >
    > > That's the kicker, isn't it? Once you get used to it, it's a workable
    > > API, if kinky and verbose. I have a real life example, too:
    > > http://people.redhat.com/zaitcev/linux/mpg123-0.59r-p3.diff
    > > But arriving on the solution costed a lot of torn hair. Look at this
    > > bald head here! And who is going to pay my medical bills when ALSA
    > > causes me ulcers, Jaroslav?
    >
    > Well, the ALSA primary goal is to be the complete HAL not hidding the
    > extra hardware capabilities to applications. So API might look a bit
    > complicated for the first glance, but the ALSA interface code for simple
    > applications is not so big, isn't?
    >
    > Also, note that app developers are not forced to use ALSA directly - there
    > is a lot of "portable" sound API libraries having an ALSA backend doing
    > this job quite effectively. We can add a simple (like OSS) API layer
    > into alsa-lib, but I'm not sure, if it's worth to do it. Perhaps, adding
    > some support functions for the easy PCM device initialization might be
    > a good idea.

    I agree. I see a lot of steam blowing and hot air from people complaining
    about ALSA. Your API is perfectly usable and aptly translates generic issues
    with any sound hardware (such as xruns and hardware buffering) without hiding
    them away so they cannot be manipulated.

    The only significant issue with ALSA is the number of tunables that you have
    to set with individual function calls. Personally, I like this approach, but
    I do always end up wrapping them in some structure, so perhaps you could have
    a "quick and dirty" one liner that would either be:

    snd_hw_set_params (fd, ... long list of sensible parameters ...)
    snd_sw_set_params (fd, ... ditto ...)

    Or, take an ioctl approach (which people here seem to love; urgh):

    struct hw_params my_hw_params = {
    PCM_LE_16,
    2,
    blah,
    };
    ...

    snd_hw_set_params (fd, &my_hw_params);
    snd_sw_set_params (fd, &my_sw_params);

    I think your time is better spent addressing the issues of "bloat" in the
    kernel side of things (the more code in userspace the better, despite what
    ridiculous statements there have been on this thread to the contrary).

    _Documentation_ clearly distinguishing between "sw" paramters and "hw"
    parameters would also be good, as when I first learnt ALSA (some 3 years
    ago), I didn't even know what these were!

    --
    Cheers,
    Alistair.

    'No sense being pessimistic, it probably wouldn't work anyway.'
    Third year Computer Science undergraduate.
    1F2 55 South Clerk Street, Edinburgh, UK.
    -
    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-04 15:29    [W:2.581 / U:2.396 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site