From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S270271AbTHGQdG (ORCPT ); Thu, 7 Aug 2003 12:33:06 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S270272AbTHGQdG (ORCPT ); Thu, 7 Aug 2003 12:33:06 -0400 Received: from ns.suse.de ([213.95.15.193]:5132 "EHLO Cantor.suse.de") by vger.kernel.org with ESMTP id S270271AbTHGQdC (ORCPT ); Thu, 7 Aug 2003 12:33:02 -0400 Date: Thu, 07 Aug 2003 18:31:01 +0200 Message-ID: From: Takashi Iwai To: Daniel Phillips Cc: Steven Newbury , davidel@xmailserver.org, linux-kernel@vger.kernel.org Subject: Re: SCHED_SOFTRR patch In-Reply-To: <200308071659.03894.phillips@arcor.de> References: <20030728202750.73149.qmail@web60001.mail.yahoo.com> <200308071659.03894.phillips@arcor.de> User-Agent: Wanderlust/2.6.1 (Upside Down) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.2 MULE XEmacs/21.4 (patch 12) (Portable Code) (i386-suse-linux) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org At Thu, 7 Aug 2003 16:59:03 +0100, Daniel Phillips wrote: > > > Under 2.6.0-test1 based kernels I have experienced quite a lote of > > drop-outs with XMMS playing mp3's with a moderate load, however, when run > > as root (with SCHED_RR) I encountered no drop-outs at all. When using > > SOFTRR under I had very choppy playback when the machine was under load. > > It was a constant jittering more than intermittent drop-outs. > > According to me, this should not happen, since your cpu usage is well below > what is supposed to be the cutoff for the realtime slice. I've only seen one > report like yours, where SOFTRR isn't working as intended. On the other > hand, I've missed a lot of lkml traffice lately, so there could be more. looking at the source code of xmms and found that xmms OSS output plugin behaves differently if the process is SCHED_RR. when xmms is started with SCHED_RR, it won't create an (another) audio thread. perhaps this explains also the difference found in some cases. well, i'm not 100% sure about this theory, now needs to practice :) please try to turn off the check of SCHED_RR in xmms/Output/OSS/audio.c, something like: realtime = xmms_check_realtime_priority(); replaced with realtime = 0; -- Takashi Iwai SuSE Linux AG - www.suse.de ALSA Developer ALSA Project - www.alsa-project.org