[Bug 91386] Tonga HDMI Audio needs CPU load

* [Bug 91386] Tonga HDMI Audio needs CPU load
@ 2015-07-18 16:46 bugzilla-daemon
  2015-07-20 19:16 ` bugzilla-daemon
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: bugzilla-daemon @ 2015-07-18 16:46 UTC (permalink / raw)
  To: dri-devel

[-- Attachment #1.1: Type: text/plain, Size: 3046 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=91386

            Bug ID: 91386
           Summary: Tonga HDMI Audio needs CPU load
           Product: DRI
           Version: DRI git
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: DRM/AMDgpu
          Assignee: dri-devel@lists.freedesktop.org
          Reporter: adf.lists@gmail.com

There are other reports I know for 270x/280x about HDMI audio needing CPU load
I've been testing again on this issue recently with R9 285 and wanted to get a
clean report out.

Cpu phenom II x4 965be now in a new mobo (asrock) with the tonga. Previous mobo
(asus) with 270x also had the issue. I see from other si bugs that people with
intel cpu/boards are also affected.

rv 790 and onboard rs880 on old mobo didn't have the issue.

rv770 on current setup didn't have the issue.

Symptoms are that with no cpu load it sounds like the same buffer gets played
out repeatedly. With a bit more load progress can be made but there are repeats
as well. With almost enough load sounds like a bit of analogue crackle.

I've recently found that saying "cpu load" is not really accurate - I can spin
cpus without curing the sound, with eg. dd if=/dev/urandom of=/dev/null or
tests like cpuburn-1.4a and certain p95/mprime loads. Using mprime it seems
what is needed is actually ram/memory controller load. The "torture test" has
three options described as -

Choose a type of torture test to run.
1 = Small FFTs (maximum heat and FPU stress, data fits in L2 cache, RAM 
not tested much).
2 = In-place large FFTs (maximum power consumption, some RAM tested).
3 = Blend (tests some of everything, lots of RAM tested).

1 = no fix, 2 = better than 1 but nowhere near right, 3 = OK sound.

Historically and recently I've tried many things with no luck -

Many sound debugging options, building without hres timers.

Disabling cool n quiet in bios.

Testing with different hdmi sinks/modes/sample rates/sizes.

I only till now used LFS + alsa but now pulse also tested as -

Yesterday I dug up an old HD and installed ubuntu 15.04 and installed/updated
fglrx - it also has the issue (I was kind of hoping it wouldn't so regs could
be compared).

The issue does not exist if I boot into windows 7 (unless it's fooling me by
always doing something behind the scenes!)

So where to go from here?

First thought - is there an obvious difference between the way the pre-si
driver code does things and what code later h/w hits?

Does the type of load needed give any clues?

Do people have this h/w on setups without the issue? I don't know what
proportion will test HDMI and then they may just look to eg. the kodi forums
and be told it's a known issue rather than filing new bugs/adding "a me too".

Anything else to test that I've missed? I don't mind spraying printfs/changing
things, but don't really know where to start in the code.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 4287 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 4+ messages in thread