Re: [OT] ALSA userspace API complexity

[Marcin Dalecki <martin@dalecki.de>]

On 2006-01-05, at 17:14, Takashi Iwai wrote:
> Because OSS API doesn't cover many things.  For example,
>
> - PCM with non-interleaved formats
> - PCM with 3-bytes-packed 24bit formats
>
> 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)
>
> Forcing OSS API means to force to process the all things above in
> the kernel.  I guess many people would disagree with it.

Not at all. What a sane system would do would be the following:

1. Provide kernel devices, which are supposed to be used by a single  
user space helper
daemon claiming them once and for ever. Those would expose the  
extensive low level hardware interface
which is required to implement this kind of processing. Those  
controlling devices would be basically
accessible by the root user.

2. Provide kernel devices, which are supposed to be used by consumer  
applications. Those would
be basically just engaged in the data lifting between the user space  
application
the kernel and the processing daemon application.

Very much a design similar what can be found in the area of terminal  
support where there is a distinction
between a pseudo tty and a tty driver. Actually if one thinks about  
it the sound output and feeding *should* be associated with a  
terminal device. Keyboard/Micro Display/Speakers - pretty much the  
same data flow.

Very much the same as the relation between the ethernet interface  
card drivers and the netowork stack support.

No the alsa mess just basically hurrying up to map the hardware  
facilities as primitively as possible in to user space for messing  
around inside some "library" which is supposed to do wonders.
-
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/