Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030590AbWAHNXr (ORCPT ); Sun, 8 Jan 2006 08:23:47 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030523AbWAHNXq (ORCPT ); Sun, 8 Jan 2006 08:23:46 -0500 Received: from gate.perex.cz ([85.132.177.35]:40320 "EHLO gate.perex.cz") by vger.kernel.org with ESMTP id S932713AbWAHNXp (ORCPT ); Sun, 8 Jan 2006 08:23:45 -0500 Date: Sun, 8 Jan 2006 14:23:43 +0100 (CET) From: Jaroslav Kysela X-X-Sender: perex@tm8103.perex-int.cz To: Olivier Galibert Cc: Takashi Iwai , ALSA development , linux-sound@vger.kernel.org, LKML Subject: Re: [OT] ALSA userspace API complexity In-Reply-To: <20060108130447.GA96834@dspnet.fr.eu.org> Message-ID: References: <20060104030034.6b780485.zaitcev@redhat.com> <20060108020335.GA26114@dspnet.fr.eu.org> <20060108130447.GA96834@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: 2464 Lines: 55 On Sun, 8 Jan 2006, Olivier Galibert wrote: > On Sun, Jan 08, 2006 at 10:42:02AM +0100, Jaroslav Kysela wrote: > > On Sun, 8 Jan 2006, Olivier Galibert wrote: > > > > > On Sat, Jan 07, 2006 at 03:32:27PM +0100, Takashi Iwai wrote: > > > > Yes, it's a known problem to be fixed. But, it's no excuse to do > > > > _everything_ in the kernel (which OSS requires). > > > > > > OSS does not require to do anything in the kernel except an entry > > > point. > > > > > > > > > > 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. > > > > But it's quite ineffecient. The kernel must switch tasks at least twice > > or more. It's the major problem with the current OSS API. > > Once. U->K or K->U is not task switching and accordingly has a very > low cost. It's changing of userspace task that is costly. And dmix > _is_ a task switch, there is no performance difference between talking > with it through shared memory and semaphores and who knows what else > and talking with it through a kernel interface. > > You should count how many U-U switches and U-K syscalls communicating > with dmix represents. Hard to do for a simple user, since the > protocol is not documented. You're in a mistake. For x86, there are no U-K syscalls for dmix and no extra U-U task switches, even the latency is same as for the direct hardware access, because we're using a lockless technique. Also, in case of use of using mutexes for other architectures, there is only task switch when mutex is locked when the real mixing is in progress (the mixing is really small time windows, so it's rare to have mutex locked). In case of a mixing daemon, you need to regulary woke up a task in a time period (probably with a highter time interval than application are feeding new samples). So you have at least one U-U task switch in the perfect conditions (all sound applications delivered data "in time"). 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/