Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751057AbWAERUU (ORCPT ); Thu, 5 Jan 2006 12:20:20 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751853AbWAERUU (ORCPT ); Thu, 5 Jan 2006 12:20:20 -0500 Received: from ds01.webmacher.de ([213.239.192.226]:16316 "EHLO ds01.webmacher.de") by vger.kernel.org with ESMTP id S1751055AbWAERUT (ORCPT ); Thu, 5 Jan 2006 12:20:19 -0500 In-Reply-To: References: <20050726150837.GT3160@stusta.de> <20060103193736.GG3831@stusta.de> <20060104030034.6b780485.zaitcev@redhat.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: =?UTF-8?Q?Tomasz_K=C5=82oczko?= , 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 Content-Transfer-Encoding: 7bit From: Marcin Dalecki Subject: Re: [OT] ALSA userspace API complexity Date: Thu, 5 Jan 2006 18:19:48 +0100 To: Takashi Iwai X-Mailer: Apple Mail (2.746.2) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2108 Lines: 54 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/