Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752279AbWAGO1Q (ORCPT ); Sat, 7 Jan 2006 09:27:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752215AbWAGO1Q (ORCPT ); Sat, 7 Jan 2006 09:27:16 -0500 Received: from mx2.suse.de ([195.135.220.15]:44755 "EHLO mx2.suse.de") by vger.kernel.org with ESMTP id S1751515AbWAGO1P (ORCPT ); Sat, 7 Jan 2006 09:27:15 -0500 Date: Sat, 07 Jan 2006 15:32:27 +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: 5144 Lines: 113 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/