Bug 91386

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.