Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030627AbWAHNcn (ORCPT ); Sun, 8 Jan 2006 08:32:43 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030610AbWAHNcn (ORCPT ); Sun, 8 Jan 2006 08:32:43 -0500 Received: from gate.perex.cz ([85.132.177.35]:46720 "EHLO gate.perex.cz") by vger.kernel.org with ESMTP id S932713AbWAHNcm (ORCPT ); Sun, 8 Jan 2006 08:32:42 -0500 Date: Sun, 8 Jan 2006 14:32:40 +0100 (CET) From: Jaroslav Kysela X-X-Sender: perex@tm8103.perex-int.cz To: Olivier Galibert Cc: Martin Drab , Takashi Iwai , ALSA development , linux-sound@vger.kernel.org, LKML Subject: Re: [OT] ALSA userspace API complexity In-Reply-To: <20060108132122.GB96834@dspnet.fr.eu.org> Message-ID: References: <20060104030034.6b780485.zaitcev@redhat.com> <20060108020335.GA26114@dspnet.fr.eu.org> <20060108132122.GB96834@dspnet.fr.eu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2336 Lines: 62 On Sun, 8 Jan 2006, Olivier Galibert wrote: > On Sun, Jan 08, 2006 at 03:26:18AM +0100, Martin Drab wrote: > > On Sun, 8 Jan 2006, Olivier Galibert wrote: > > > > > > And if the application doesn't support, who and where converts it? > > > > With OSS API, it's a job of the kernel. > > > > > > Once again no. Nothing prevents the kernel to forward the data to > > > userland daemons depending on a userspace-uploaded configuration. > > > > I think that the point was, that switching from userspace to kernelspace > > then to userspace again and back to kernelspace in order to do something, > > that could have been done directly in the userspace, and though could save > > those two unnecessary switches, is an unnecessary overhead, which may not > > necessarily be that insignificant if it's done so often (which for > > streaming audio is the case). > > You all seem to forget that dmix is in userspace in a different task > too. Because it is really not. The mixing is done directly to the mmaped DMA buffer. > > Why doing things complicated when there is no evident gain from it, > > or is there? > > No evident gain? Wow. What about: > - stopping crippling the OSS api We're not doing that. We're just showing that OSS API and useability has it's own problems, too. > - having a real kernel api for which you can make different libraries > depending on the need of the users > > - stop making a fundamentally unsecure shared library mandatory ALSA kernel API is real and binary compatible. If someone require to write an own library, we will document this API, of course, too. > - opening the possibility of writing plugins to people without a PhD > in lattice QCD. Already done. We have official plugin SDK in alsa-lib to create user space drivers. If you have some questions or bug-reports (missing docs etc), please, fill a bug report. Also, you can use very simple LADSPA plugin style, because alsa-lib can use LADSPA plugins directly, too. Jaroslav ----- Jaroslav Kysela Linux Kernel Sound Maintainer ALSA Project, SUSE Labs - 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/