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: Sat, 02 Nov 2013 11:50:09 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0306867081==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id E54AAF07CA for ; Sat, 2 Nov 2013 04:50:09 -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 --===============0306867081== Content-Type: multipart/alternative; boundary="1383393009.46D4cEA3.22015"; charset="us-ascii" --1383393009.46D4cEA3.22015 Date: Sat, 2 Nov 2013 11:50:09 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #43 from Pierre Ossman --- (In reply to comment #40) > > 1. The 25175 clock at 44.1 kHz is out of spec. There are no correct values to > > make it in spec. So either change the clock, rely on hw calculated values, or > > hope that sinks tolerate the large N. > > 4th alternative is to round CTS and leave the glitches in on those modes. I > might even slightly prefer that than produce out-of-spec N, but that is just > my preference and I don't really have any real-world data of course... If we truncate the clock to 25274 instead instead of rounding it up, we can get sensible N/CTS. Is that something that's possible to do? I don't know how the code that generates the clock looks like. -- You are receiving this mail because: You are the assignee for the bug. --1383393009.46D4cEA3.22015 Date: Sat, 2 Nov 2013 11:50:09 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8"

Comment # 43 on bug 69675 from 
(In reply to comment #40)
> > 1. The 25175 clock at 44.1 kHz is out of spec. There are no correct values to
> > make it in spec. So either change the clock, rely on hw calculated values, or
> > hope that sinks tolerate the large N.
> 
> 4th alternative is to round CTS and leave the glitches in on those modes. I
> might even slightly prefer that than produce out-of-spec N, but that is just
> my preference and I don't really have any real-world data of course...

If we truncate the clock to 25274 instead instead of rounding it up, we can get
sensible N/CTS. Is that something that's possible to do? I don't know how the
code that generates the clock looks like.

You are receiving this mail because:
  • You are the assignee for the bug.
--1383393009.46D4cEA3.22015-- --===============0306867081== 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 --===============0306867081==--