Bug 91386

Summary: Tonga HDMI Audio needs CPU load
Product: DRI Reporter: Andy Furniss <adf.lists>
Component: DRM/AMDgpuAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED MOVED QA Contact:
Severity: normal    
Priority: medium CC: lorenz.bona, mabo
Version: DRI git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description Andy Furniss 2015-07-18 16:46:29 UTC
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.
Comment 1 Alex Deucher 2015-07-20 19:16:30 UTC
All the gpu driver does is enable the audio stream in the video stream.  It's not clear to me whether this is a problem with the audio driver or the gpu driver.  Does audio work ok with the proprietary Linux driver?
Comment 2 Andy Furniss 2015-07-20 23:17:51 UTC
(In reply to Alex Deucher from comment #1)

> Does audio work ok with the proprietary Linux driver?

No, fglrx on ubuntu 15.04 has the same issue.
Comment 3 Martin Peres 2019-11-19 08:06:22 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/55.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.