From owner-freebsd-gecko@FreeBSD.ORG Thu Jun 28 19:30:51 2012 Return-Path: Delivered-To: freebsd-gecko@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A9EB106564A for ; Thu, 28 Jun 2012 19:30:51 +0000 (UTC) (envelope-from jbeich@tormail.org) Received: from server2.allsitecontrol.com (server2.allsitecontrol.com [63.143.36.210]) by mx1.freebsd.org (Postfix) with ESMTP id 1057D8FC08 for ; Thu, 28 Jun 2012 19:30:50 +0000 (UTC) Received: from tor19.anonymizer.ccc.de ([31.172.30.2]:55916 helo=internal.tormail.org) by server2.allsitecontrol.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.77) (envelope-from ) id 1SkKQP-003iQB-9j; Thu, 28 Jun 2012 15:30:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tormail.org; s=tm; h=Message-Id:X-TorMail-User:Content-Type:MIME-Version:References:Date:Subject:Cc:To:From; bh=kdWHKVBh5zZaGEeZZmTUsTorS0+3XatjD9+TZ4uhJjQ=; b=s6BC2ZRMvtNkFT6SAZoe2OKX6z0P73Aema+6NHWxtRZH7Ww928zqwJh+YxSPArUiN4n0Rmm05d7LSQ2kq0muT1zO2udWXNRlaJJYKr6dsmhlm4ZP/YqvRQ8am83NtEPU0oT4v1fkH0E24U7cP89iW/FC/dInpyFKYeEMPkFeXSk=; Received: from jbeich by internal.tormail.org with local (Exim 4.63) (envelope-from ) id 1SkKOt-000LQ8-5k; Thu, 28 Jun 2012 19:29:12 +0000 From: Jan Beich To: AN Date: Thu, 28 Jun 2012 16:29:36 -0300 References: <86d35ikpkd.fsf@tormail.org> MIME-Version: 1.0 Content-Type: text/plain X-TorMail-User: jbeich Message-Id: <1SkKOt-000LQ8-5k@internal.tormail.org> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server2.allsitecontrol.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tormail.org X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-gecko@FreeBSD.org Subject: Re: issue with VP8 and Ogg video X-BeenThere: freebsd-gecko@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Gecko Rendering Engine issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 19:30:51 -0000 Jan Beich writes: > AN writes: > >> Hi: >> >> I want to report an issue I have playing HTML5 video in Firefox. >> >> - if you pause or stop a video it takes time (10-30 secs) before the sound >> stops playing >> >> - after viewing a video Firefox cpu utilization pegs at 100% and stays >> there until you exit firefox and restart it. >> >> I have seen this problem before with Adobe Flash, it seems that it has >> been fixed with Flash. Now it happens with VP8, and Ogg. I would >> like to help to troubleshoot this if I can. I am not a developer, >> just a lowly user. > [...] > > Try to test[1] on www/linux-firefox to verify if this a platform > specific bug. I've pushed a few options to choose audio backend in Nightly port. It should help debug audio issues like this one. And from my limited testing on youtube (some could be local issues): alsa->oss + cubeb = no sound (but aplay works) alsa->oss + sydney = fast-forward video alsa->pulse + cubeb = fast-forward video + noise alsa->pulse + sydney = works fine pulse->alsa + cubeb = works fine pulse->alsa + sydney = busy wait during pause (like native OSS) pulse->oss + cubeb = works fine pulse->oss + sydney = busy wait during pause (like native OSS) > In my case on Nightly after pause takes effect (a few *seconds* after > hitting it) firefox cpu usage ramps up to 100% in audio_callback around > pthread_mutex_unlock, i.e. sydney_audio_oss.c:459. > And if I close the tab while sound still plays (whether or not I hit > pause) the bug would not appear. Nevermind, cpu utilization often drops to normal after closing the tab, it just takes time (around 10s here). Sometimes opening another tab with video and closing it shortly after helps. > [1] if you manage to make sound work (I haven't) despite linux aplay(1) working fine; > a few related diffs attached, may or may not make a difference Correction, I do have sound working fine on linux-firefox up to 13.0 and even on Nightly if I disable libcubeb. But as threading in glibc->linuxulator works differentry than our libthr results aren't useful.