Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750983AbWAJJyk (ORCPT ); Tue, 10 Jan 2006 04:54:40 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750981AbWAJJyk (ORCPT ); Tue, 10 Jan 2006 04:54:40 -0500 Received: from gate.perex.cz ([85.132.177.35]:56723 "EHLO gate.perex.cz") by vger.kernel.org with ESMTP id S1750891AbWAJJyi (ORCPT ); Tue, 10 Jan 2006 04:54:38 -0500 Date: Tue, 10 Jan 2006 10:54:32 +0100 (CET) From: Jaroslav Kysela X-X-Sender: perex@tm8103.perex-int.cz To: Hannu Savolainen Cc: Joern Nettingsmeier , Olivier Galibert , Tomasz K?oczko , Pete Zaitcev , Alistair John Strachan , Adrian Bunk , 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: Message-ID: References: <20050726150837.GT3160@stusta.de> <20060103193736.GG3831@stusta.de> <20060104030034.6b780485.zaitcev@redhat.com> <43BDA02F.5070103@folkwang-hochschule.de> <20060105234951.GA10167@dspnet.fr.eu.org> <43BDB858.5060500@folkwang-hochschule.de> 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: 1421 Lines: 32 On Fri, 6 Jan 2006, Hannu Savolainen wrote: > What happens if some system load peak delays the application by 20 ms? The > result is complete failure. What is the ALSA (API) feature OSS doesn't > have that makes it able to predict what kind of output the application > should have fed to the device during the (about) 20 ms period of silence? > > The fact is that there is nothing the audio subsystem can do to recover > the situation. For this very simple reason the OSS API lacks everything > that would be necessary to cope with this kind of problems. Applications should be notified that something is broken. If you have a professional environment, you really need to know, if the output survived all scheduling peaks and the audio data are delivered from/to I/O in time. Also, in the standard consumer environment is good to know that the system have some trouble to deliver data in time (motivating developers of core Linux kernel code or subsystems, or motivating app programers to set the correct scheduling parameters) to fix remaining problems. 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/