Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751484AbWAEQJo (ORCPT ); Thu, 5 Jan 2006 11:09:44 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751492AbWAEQJo (ORCPT ); Thu, 5 Jan 2006 11:09:44 -0500 Received: from mx2.suse.de ([195.135.220.15]:11454 "EHLO mx2.suse.de") by vger.kernel.org with ESMTP id S1751470AbWAEQJn (ORCPT ); Thu, 5 Jan 2006 11:09:43 -0500 Date: Thu, 05 Jan 2006 17:14:43 +0100 Message-ID: From: Takashi Iwai To: Tomasz =?ISO-8859-2?Q?K=B3oczko?= Cc: Jaroslav Kysela , Pete Zaitcev , Alistair John Strachan , Adrian Bunk , Olivier Galibert , Tomasz Torcz , Jan Engelhardt , Andi Kleen , ALSA development , James@superbug.demon.co.uk, sailer@ife.ee.ethz.ch, linux-sound@vger.kernel.org, zab@zabbo.net, kyle@parisc-linux.org, parisc-linux@lists.parisc-linux.org, jgarzik@pobox.com, Thorsten Knabe , zwane@commfireservices.com, LKML Subject: Re: [OT] ALSA userspace API complexity In-Reply-To: References: <20050726150837.GT3160@stusta.de> <20060103193736.GG3831@stusta.de> <20060104030034.6b780485.zaitcev@redhat.com> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 MULE XEmacs/21.5 (beta21) (corn) (+CVS-20050720) (i386-suse-linux) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4034 Lines: 99 At Thu, 5 Jan 2006 16:07:02 +0100 (CET), Tomasz K?oczko wrote: > > On Thu, 5 Jan 2006, Jaroslav Kysela wrote: > > > 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. > > 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? > 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. (snip) > In case ALSA now questions are very basic: > > - all hardware mixers are very simillar with very izomorphic interface > (read this as: this can be very easy abstracted) and we have only one > other case with soft mixing when this hardwware must be emulated in > software .. so all this details can be rolled to one leyer on kernel > level. > So: why all mixing details are not in kernel space ? The problem is not the interface but the implementation. > - KNOWN FACT is OSS provides simpler API for user space for handle > usual cases. Please define "usual cases". > Why Linux can't provide only OSS API abstraction for user space > application ? And/or why ALSA developers want to replace this by > mostly bloated and pourly documented ALSA user space API ? 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. 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/