Re: [OT] ALSA userspace API complexity

[Takashi Iwai <tiwai@suse.de>]

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