From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 69675] audio broken in 24Hz/24p since 3.11 (regression) Date: Thu, 31 Oct 2013 21:02:43 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1604709127==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 8B9D7F003A for ; Thu, 31 Oct 2013 14:02:43 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1604709127== Content-Type: multipart/alternative; boundary="1383253363.8EBAE0a2.14318"; charset="us-ascii" --1383253363.8EBAE0a2.14318 Date: Thu, 31 Oct 2013 21:02:43 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #30 from Alex Deucher --- (In reply to comment #29) > Hm, so actual problems were confirmed fixed with this? That seems rather > strange, since that would mean the hardware counted the clock cycles wrong > for the CTS value... Maybe the HW doesn't do it per-spec, instead > calculating CTS in some other way? Yes. Using the sw cts/n values resulted in better results across asics compared to the alternative fix (using the actual pll clock for the dto calculation). Using the hw cts/n values lead to playback speed issues on some asics. -- You are receiving this mail because: You are the assignee for the bug. --1383253363.8EBAE0a2.14318 Date: Thu, 31 Oct 2013 21:02:43 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8"

Comment # 30 on bug 69675 from 
(In reply to comment #29)

> Hm, so actual problems were confirmed fixed with this? That seems rather
> strange, since that would mean the hardware counted the clock cycles wrong
> for the CTS value... Maybe the HW doesn't do it per-spec, instead
> calculating CTS in some other way?

Yes.  Using the sw cts/n values resulted in better results across asics
compared to the alternative fix (using the actual pll clock for the dto
calculation).  Using the hw cts/n values lead to playback speed issues on some
asics.

You are receiving this mail because:
  • You are the assignee for the bug.
--1383253363.8EBAE0a2.14318-- --===============1604709127== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============1604709127==--