Re: [OT] ALSA userspace API complexity

[Jaroslav Kysela]

On Thu, 5 Jan 2006, Tomasz Kłoczko wrote:

> On Wed, 4 Jan 2006, Jaroslav Kysela wrote:

> > 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?
> 
> Sorry Jaroslav byt this not unix way.
> Wny applications myst know anything about hardware layer ?
> In unix way all this details are rolled on kernel layer.

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.

> > 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.
> 
> If we have so many "portable" sound API libraries .. look most of them 
> uses the same way for handle sound on kernel interaction. Is this 
> complicated ALSA way is realy neccessary ? For example .. jackd can use 
> OSS API for handle sound device.

The grounds of ALSA APIs are not complicated. The complicated are the 
extra features (like stream linking) which can be included conditionaly. 
Note that during API development, mostly users requesting extra features 
were speak loudly, others were only watching.

We know that the reduction requests have points for embedded systems etc.
And we will definitely try to sort "real-core" and "extra" things.

Also, note that if OSS used a library to access to sound devices, we won't 
ever have such problems with the OSS API redirection to another API.
I already created a prototype of OSS API redirector (part of alsa-oss 
package), see:

http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-oss/oss-redir/README?rev=1.1&view=markup
http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-oss/oss-redir/oss-redir.h?rev=1.6&view=markup
http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-oss/oss-redir/oss-redir.c?rev=1.9&view=markup

But it's a question, if OSS application developers take this proposal.

						Jaroslav

-----
Jaroslav Kysela <perex@xxxxxxx>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs