From owner-freebsd-multimedia Fri Jan 4 12:31:33 2002 Delivered-To: freebsd-multimedia@freebsd.org Received: from cs.ucla.edu (Mordred.CS.UCLA.EDU [131.179.192.128]) by hub.freebsd.org (Postfix) with ESMTP id 993B837B416 for ; Fri, 4 Jan 2002 12:31:29 -0800 (PST) Received: (from scottm@localhost) by cs.ucla.edu (8.11.6/8.11.6) id g04KVTW07376 for freebsd-multimedia@freebsd.org; Fri, 4 Jan 2002 12:31:29 -0800 (PST) (envelope-from scottm) Date: Fri, 4 Jan 2002 12:31:29 -0800 From: Scott Michel To: freebsd-multimedia@freebsd.org Subject: xmms stutterrrrrrrrring Message-ID: <20020104203129.GC7129@mordred.cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.24i Sender: owner-freebsd-multimedia@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a new one I've encoutered (4.5-PRERELEASE): Playing a stream causes xmms 1.2.5 to stutter and take over the machine when the stream dries up due to congestion. It's as if the sound output thread plays the same buffer over and over while waiting for new data from the stream (which is congested, ergo, none will be coming...) Is this fixable via a patch or just an architectural bug in xmms? Can someone point me in the right direction in the xmms code so I can maybe craft a patch? Or might this be a problem in libc_r? -scooter -- Scott Michel | No research ideal ever survives UCLA Computer Science | contact with implementation. PhD Graduate Student | !! Futuaris nisi irrisus ridebis !! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message