https://bugs.freedesktop.org/show_bug.cgi?id=69675
Martin Peres changed:
What|Removed |Added
Resolution|--- |INVALID
Status|REOPENED
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #53 from Rainer Hochecker ---
We did measure system clock against refresh rate. When running at 50hz or 60hz,
refresh rate seems to be fast whereas when running at 24 is is behind. Means
that not only 24hz is affected but all refresh
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #52 from Pierre Ossman ---
(In reply to comment #51)
> Sorry, to warm up this thread. I have also seen that 24p playback is now
> "working" again. If one measure the audio vs the video clock. One is approx
> 10ms behind per 6
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #51 from Peter Fr?hberger ---
Sorry, to warm up this thread. I have also seen that 24p playback is now
"working" again. If one measure the audio vs the video clock. One is approx
10ms behind per 6 seconds, which is compensated by
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #50 from Pierre Ossman ---
(In reply to comment #49)
> (In reply to comment #47) (In reply to comment #48)
> > CEC HDMI spec
>
> Just a nitpick, but CEC is Consumer Electronics Control, an unrelated subset
> of the HDMI spec. You
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #49 from Anssi Hannula ---
(In reply to comment #47) (In reply to comment #48)
> CEC HDMI spec
Just a nitpick, but CEC is Consumer Electronics Control, an unrelated subset of
the HDMI spec. You may be thinking of CEA (Consumer
https://bugs.freedesktop.org/show_bug.cgi?id=69675
Pierre Ossman changed:
What|Removed |Added
Attachment #88450|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #48 from Pierre Ossman ---
Created attachment 88776
--> https://bugs.freedesktop.org/attachment.cgi?id=88776=edit
patch 2/2: improve ACR calculation
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=69675
Pierre Ossman changed:
What|Removed |Added
Attachment #88476|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #46 from Alex Deucher ---
Patch looks good to me. I'll probably wait until drm-next is merged with 3.12
so that it will apply cleanly. If you want to attach a git patch, that would
be great :)
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #45 from Pierre Ossman ---
Alex? Comments?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #44 from Anssi Hannula ---
(In reply to comment #43)
> (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
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
> >
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #42 from Pierre Ossman ---
(In reply to comment #41)
> I think with a) the "table" was used and with b) the values were calculated.
> So both seem fine. I am a bit afraid with the "out of spec" values - but it
> did not harm here and
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #41 from Peter Fr?hberger ---
I tested on a 3.12-rc7+ kernel in the following combination:
a) sw cts/n values revert + pierre ossman patch applied
All fine - watched a whole 24p movie with dts-hd
b) kept 3.12-rc7+ as is and only
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #40 from Anssi Hannula ---
The changes look sound to me.
I had already forgotten that the table values were off for the rounded clocks
(even though I had mentioned it in comment #5).
Also, I see now that as the DTO is also set
https://bugs.freedesktop.org/show_bug.cgi?id=69675
Pierre Ossman changed:
What|Removed |Added
Attachment #88476|0 |1
is patch|
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #39 from Pierre Ossman ---
Created attachment 88476
--> https://bugs.freedesktop.org/attachment.cgi?id=88476=edit
properly calculate both N and CTS
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #38 from Peter Fr?hberger ---
Nope it is okay. You had everything I needed in your previous post (could
easily copy the two functions and the struct) - will report back later.
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #37 from Pierre Ossman ---
(In reply to comment #36)
> Could you post a patch, then I can try on my hardware.
I was hoping to be lazy, but I'll sort it out then. :)
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #36 from Peter Fr?hberger ---
Could you post a patch, then I can try on my hardware.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #35 from Pierre Ossman ---
(In reply to comment #28)
> Created attachment 88450 [details] [review]
> use fractional fb div on DCE4+
>
> Does this patch help? This should allow the pll value to more closely match
> the actual
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #34 from Peter Fr?hberger ---
I need something to regression test.
With xbmc I can sync to the video clock and drop / dupe audio, when they are
running into different directions.
Example:
Watching 1080i50 (was better with the SW
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #33 from Alex Deucher ---
(In reply to comment #31)
> As send via E-Mail, I told the same with 24.0 and 24p having these issues.
> The "sw cts/n values" patch made audio drops with 50 / 60hz much better -
> but I also have to admit:
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #32 from Peter Fr?hberger ---
To add: I tested with
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=de926800b155886c61b06146e28c0ba2e6fafc39
reverted and use "fractional fb div on DCE4+" applied
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #31 from Peter Fr?hberger ---
As send via E-Mail, I told the same with 24.0 and 24p having these issues. The
"sw cts/n values" patch made audio drops with 50 / 60hz much better - but I
also have to admit:
Reverting the "sw cts/n
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
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #29 from Anssi Hannula ---
> Use the driver calculated CTS and N values rather than
> having hardware generate them. This allows us to use
> the modeline pixel clock rather than the actual pll clock
> when setting up the dto for
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #28 from Alex Deucher ---
Created attachment 88450
--> https://bugs.freedesktop.org/attachment.cgi?id=88450=edit
use fractional fb div on DCE4+
Does this patch help? This should allow the pll value to more closely match
the
https://bugs.freedesktop.org/show_bug.cgi?id=69675
Pierre Ossman changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bugs.freedesktop.org/show_bug.cgi?id=69675
Tom Yan changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #25 from Tom Yan ---
I am just testing the fixes with Linux 3.12-rc6, which is built with this:
https://aur.archlinux.org/packages/linux-mainline/
But only worse things happened. It seems that I can't have HDMI sound at all
now.
https://bugs.freedesktop.org/show_bug.cgi?id=69675
Tom Yan changed:
What|Removed |Added
CC||tom.ty89 at gmail.com
--- Comment #24 from
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #22 from Pierre Ossman pierre-bugzi...@ossman.eu ---
So what's the verdict? Can these patches be applied? It would be nice to be
able to go back to a stock kernel. :)
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #23 from Alex Deucher ag...@yahoo.com ---
Already queued for 3.12 fixes. Should show up in the next RC.
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=69675
Alex Deucher ag...@yahoo.com changed:
What|Removed |Added
Attachment #86739|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #21 from Alex Deucher ag...@yahoo.com ---
(In reply to comment #19)
Subject: [PATCH 3/3] drm/radeon: use hw generated CTS/N values for audio
Just checking: What N value does the Hw use in that mode? The ones written
in by the
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #14 from Pierre Ossman pierre-bugzi...@ossman.eu ---
(In reply to comment #3)
Created attachment 86598 [details] [review]
use hw generated cts and n values rather than the sw programmed values
Does this patch help? If not, it
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #15 from Pierre Ossman pierre-bugzi...@ossman.eu ---
(In reply to comment #4)
Something like this:
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
b/drivers/gpu/drm/radeon/r600_hdmi.c
index b0fa600..f7d2766 100644
---
https://bugs.freedesktop.org/show_bug.cgi?id=69675
Alex Deucher ag...@yahoo.com changed:
What|Removed |Added
Attachment #86598|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #17 from Alex Deucher ag...@yahoo.com ---
Created attachment 86740
-- https://bugs.freedesktop.org/attachment.cgi?id=86740action=edit
patch 2/3
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #18 from Alex Deucher ag...@yahoo.com ---
Created attachment 86741
-- https://bugs.freedesktop.org/attachment.cgi?id=86741action=edit
patch 3/3
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #19 from Anssi Hannula an...@mageia.org ---
(In reply to comment #16)
+ u64 n, d;
+
+ if (*CTS == 0) {
+ n = (u64)clock * N;
+ d = 128ULL * (u64)freq;
+ *CTS = div64_u64(n, d);
+
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #12 from Christian König deathsim...@vodafone.de ---
(In reply to comment #3)
Created attachment 86598 [details] [review]
use hw generated cts and n values rather than the sw programmed values
Does this patch help? If not, it
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #13 from Andy Furniss adf.li...@gmail.com ---
(In reply to comment #9)
(In reply to comment #1)
IIRC it was the XBMC people that wanted the ntsc variants in the first place
as their player defaults to sync to video exactly and
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #1 from Andy Furniss adf.li...@gmail.com ---
IIRC it was the XBMC people that wanted the ntsc variants in the first place as
their player defaults to sync to video exactly and would need to resample sound
at 24Hz because of this
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #2 from Alex Deucher ag...@yahoo.com ---
From IRC:
Anssi agd5f: you might've seen already, but the 23.976 Hz pixel clock
74175.824175 is rounded up to 74176 in Ville's commit, but
r600_hdmi_predefined_acr[] table contains 74175 so it
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #3 from Alex Deucher ag...@yahoo.com ---
Created attachment 86598
-- https://bugs.freedesktop.org/attachment.cgi?id=86598action=edit
use hw generated cts and n values rather than the sw programmed values
Does this patch help? If
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #4 from Alex Deucher ag...@yahoo.com ---
Something like this:
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
b/drivers/gpu/drm/radeon/r600_hdmi.c
index b0fa600..f7d2766 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #5 from Anssi Hannula an...@mageia.org ---
To expand a bit on my earlier comment that Alex pasted:
HDMI sends ACR packets in the stream that will allow the sink to recover the
audio clock. Two values are sent:
N: Divisor used on the
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #6 from Alex Deucher ag...@yahoo.com ---
(In reply to comment #5)
(In reply to comment #4)
Something like this:
Not really, the selection doesn't work like that - clock has to match
exactly to the table value, it is not an
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #7 from Anssi Hannula an...@mageia.org ---
(In reply to comment #6)
I just meant to patch the table so that you end up using the pre-defined
values for CTS and N rather than calculating them from the formula.
{ xxx, 11648,
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #8 from Andy Furniss adf.li...@gmail.com ---
(In reply to comment #2)
From IRC:
Anssi agd5f: you might've seen already, but the 23.976 Hz pixel clock
74175.824175 is rounded up to 74176 in Ville's commit
FWIW I guess he did this
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #9 from Pierre Ossman pierre-bugzi...@ossman.eu ---
(In reply to comment #1)
IIRC it was the XBMC people that wanted the ntsc variants in the first place
as their player defaults to sync to video exactly and would need to resample
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #10 from Pierre Ossman pierre-bugzi...@ossman.eu ---
(In reply to comment #6)
(In reply to comment #5)
(In reply to comment #4)
Something like this:
Not really, the selection doesn't work like that - clock has to match
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #11 from Pierre Ossman pierre-bugzi...@ossman.eu ---
(In reply to comment #10)
So what should I actually try for the second patch? What you wrote? Or the
value from the mode line? :)
Which were the same, so don't mind me...
--
56 matches
Mail list logo
