lkml.org 
[lkml]   [2006]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [OT] ALSA userspace API complexity
    At Thu, 5 Jan 2006 21:13:25 +0100 (CET),
    Tomasz Kłoczko wrote:
    >
    > [..]
    > >>> It means that you are saying that kernel should be bigger and bigger.
    > >>> Please, see the graphics APIs. Why we have X servers in user space (and
    > >>> only some supporting code is in the kernel) then? It's because if we
    > >>> would move everything into kernel it will be even more bloated. The kernel
    > >>> should do really the basic things like direct hardware access, DMA
    > >>> transfer etc.
    > >>
    > >> List all neccessary feactures and abstract them. Below this layer you
    > >> can plug to this all device drivers. Where is the problem ?
    > >> Cureent way moves some importand details like mixing to user space
    > >> library.
    > >> All abstraction are NOW coded but some parts of this abstraction are on
    > >> library level and you are wrong because this still ONE abstraction
    > >> (not multiple/growing).
    > >> Moving some patrs of this abstraction to user space level DISSALLOW secure
    > >> manage because you do not have *single point of entry to this layer*. Try
    > >> plug library abstraction to SELinux layer. Can you do this with ALSA way ?
    > >
    > > I don't understand this. The alsa-lib doesn't skip the h/w access.
    > > It still accesses the device file as usual, open/close/ioctls. If the
    > > h/w to do softmix is restricted, you can't use it, too.
    > > Or, am I missing something else?
    >
    > Soft mixing is performed by writing to allocated shared memory block.
    > Try to use SELinux on dissalow use SHM only for mixing souds.
    > In case performing ALL (possible) mixing tricks you have SINGLE point of
    > entry from any application. Using SHM with r/w permission allow one
    > allicattions dump sound streams writed by other applications.

    Yes, it's a known problem to be fixed. But, it's no excuse to do
    _everything_ in the kernel (which OSS requires).


    > >> If you have sound device with hardware mixer(s) ALSA now work
    > >> transparently.
    > >> If you have sound device without this soft mixing is moved to user space
    > >> .. but applications do not need know about this even now because all
    > >> neccessary details are handled on library level. Is it ?
    > >> So question is: why the hell *ALL* mixing details are not moved to kernel
    > >> space to SIMPLE and NOT GROWING abstraction ?
    > >
    > > Because many people believe that the softmix in the kernel space is
    > > evil. The discussion aboult this could be a long thread.
    >
    > Moment .. are you want to say: there is no compact mixing abstraction
    > layer in ALSA because because ALSA is developed by believers ? (not
    > technicians/enginers ?)
    > Sorry .. be so kind and try to answer on my question using only stricte
    > *technical arguments*.

    I stated above because I know it will be a discussion without a clear
    end. From the convenence viewpoint, doing everthing in the kernel
    including the software mixing is fine. But, do you want to it -- to
    do EVERTHING in the kernel with a great risk of system down and the
    programming restrictions (no FP, etc)?


    > > Because OSS API doesn't cover many things. For example,
    > >
    > > - PCM with non-interleaved formats
    > > - PCM with 3-bytes-packed 24bit formats
    >
    > Not true. Download OSS from opensound. You can find in soundcard.h
    > AFMT_S24_PACKED define.

    And if the application doesn't support, who and where converts it?
    With OSS API, it's a job of the kernel.

    > > These functions are popluar on many sound devices.
    > >
    > > In addition, imagine how you would implement the following:
    > >
    > > - Combination of multiple devices
    > > - Split of channels to concurrent accesses
    > > - Handling of floating pointer samples
    > > - Post/pre-effects (like chorus/reverb)
    >
    > Are you want say something like: architesture of OSS is so bad there is no
    > civilized way for extending this ? (except: chorus/reverb are now handled
    > by comercial OSS).
    > Correct me if I'm wrong: his not true.

    Could you tell me how do you handle the floating point in the kernel
    code?

    > This unhides one fact: *ALSA and OSS are mostly izomorphic* (look on
    > similarities ALSA and OSS device drivers architecture).
    >
    > And if it is true there was/is no strong arguments for droping OSS and
    > replace this by ALSA. As I sayd ALSA is only on Linux. Using OSS allow
    > easier develpment soud support in user space applications for some group
    > of currently used unices. This is IMO strong argument .. much stronger
    > than existing or not group of belivers. For me now switching to ALSA have
    > only *political groud* .. nothing more. Interesting .. how long Linux can
    > survive without looking on some economic aspects ?

    Don't get me wrong. I, as ALSA developer, don't believe that OSS API
    would disappear. The API will remain. But the implementation may
    change. That's all what is happening -- Adrian has asked to drop the
    codes which are implemented differently (on ALSA). No one requested
    to drop the API support.


    Takashi
    -
    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-07 15:29    [W:4.070 / U:0.092 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site