Bug 86351 - HDMI audio garbled output on Radeon R9 280X
Summary: HDMI audio garbled output on Radeon R9 280X
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-dri
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-15 19:22 UTC by Christian Birchinger
Modified: 2019-03-23 19:20 UTC (History)
8 users (show)

See Also:
Kernel Version: 3.17
Subsystem:
Regression: No
Bisected commit-id:


Attachments
dmesg output (76.26 KB, text/plain)
2014-10-15 19:22 UTC, Christian Birchinger
Details
lsmod output (3.00 KB, text/plain)
2014-10-15 19:22 UTC, Christian Birchinger
Details
asound /proc info (222 bytes, application/x-gzip)
2014-10-15 19:23 UTC, Christian Birchinger
Details
dmesg.log (69.54 KB, text/plain)
2015-07-04 22:31 UTC, Lorenzo Bona
Details

Description Christian Birchinger 2014-10-15 19:22:21 UTC
Created attachment 153891 [details]
dmesg output

Any sound played back over HDMI results in garbled audio output.

When playing audio at 24000hz or below (19200Hz also tested) playback
starts to work normaly without the constant choppyness.

What also works is 44100Hz in Mono.

It behaves like a data bandwith issue that kicks in above 24000hz Stereo
or 44100Hz Mono.

All test are done directly talking to the alsa device.
This means no pulseaudio or dmix or similar processing.
"plughw" had to be used because the hardware does not
allow low rates like 24000.

During all Test a perfectly fine and stable 1080p image is displayed
over HDMI. (No dropouts at all).

This hardware setup has also be successfully tested using Windows.
(Incl. Multi channel PCM 6.0 for lot's of audio bandwidth)

Working Audio Tests:
--------------------
speaker-test -r 24000 -c2
speaker-test -r 24000 -c6 (multi channel PCM works too)

mpg123 -r 24000 <file>
mpg123 -m -r 44100 <file>

The peer format detection is pcm 2.0 44100 or 48000 here.
It appears the format link doesn't matter, only the actual
data bandwidth that's being used)

Garbled Audio Tests:
--------------------
speaker-test -r 48000 -c2
speaker-test -r 48000 -c6

mpg123 -r 44100 <file>


All passthru formats (dts, dolby d, pcm multi channel) get detected
my the destination, but after a short period it loses the link and
tries to resync.

What previously also worked is a HD5570 in the same system which i
no longer have access to though. Not sure about the kernel used back
then.
Comment 1 Christian Birchinger 2014-10-15 19:22:47 UTC
Created attachment 153901 [details]
lsmod output
Comment 2 Christian Birchinger 2014-10-15 19:23:36 UTC
Created attachment 153911 [details]
asound /proc info
Comment 3 Christian Birchinger 2015-01-11 11:53:51 UTC
Retried with kernel 3.18.2:

If i constantly open new windows or constantly switch virtual desktops really
fast or do other things that keeps the desktop busy, the sound plays back
normaly.

As soon as the desktop is "idle" the sound becomes garbled again.

Playing a video also has working sound. However only stereo seems to work.
There's not enough for passthru Dolby D. The receiver gets a Dolby D link
from time to time but loses it again shortly after.

As if theres not enough bandwidth reserved for audio during desktop "idle time"
or some weird power save mode.
Comment 4 Andy Furniss 2015-01-11 12:20:05 UTC
You are not alone, I get this on my R9270X  -

https://bugs.freedesktop.org/show_bug.cgi?id=77677
Comment 5 Alex Deucher 2015-01-12 21:51:56 UTC
Does forcing the GPU clocks to high help?  E.g., as root:
echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level
Comment 6 Andy Furniss 2015-01-13 16:18:25 UTC
(In reply to Alex Deucher from comment #5)
> Does forcing the GPU clocks to high help?  E.g., as root:
> echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level

Doesn't help for me.
Comment 7 Alex Deucher 2015-01-13 16:23:58 UTC
If you are using CPU governor, does forcing the CPU power state to a stable state help?
Comment 8 Andy Furniss 2015-01-13 16:41:52 UTC
(In reply to Alex Deucher from comment #7)
> If you are using CPU governor, does forcing the CPU power state to a stable
> state help?

No, I've tried many things as recorded in the FDO bug I linked.

It's certainly a strange one, but the only way to get working sound I've found is to have enough CPU load across all my CPUs (just maxing one won't do).

By luck for me my only real use case is HDTV and decoding in s/w is enough load.

When there is no load it's like just one chunk of buffer gets repeated and this may initially contain old sound from a previous loaded run.

Doing not much will advance the buffer. With more, but not enough, load the sound is almost OK, but there is a bit of crackle.

This does seem to need purely CPU load, as I said in the other bug I can reproduce from fbcon without X and temporarily "fix" the sound my compiling something with make -j5.

My CPU is AMD Phenom II x4 965be, but IIRC others have seen this with intel.

Whether working or not interrupt counters rise at the same rate.

Previous card = HD4890 didn't have the issue in the same box with the same TV with almost the same s/w.
Comment 9 Christian Birchinger 2015-01-13 17:42:46 UTC
"make -j8" gets usable sound here too.

In my case it's an Intel i7-4770 system.

The only hardware i swaped out was a 5570 for a R9 280X.
Comment 10 Lorenzo Bona 2015-07-04 22:31:01 UTC
I'm experiencing the same issue with a R7-265 video card.
HDMI sound is garbled until I put some load on CPUs.

ie starting/running a game is enough. 
As soon as the load on CPUs drops audio becomes garbled again.

Any hint or test I can do?

running kernel from agd5f's git, branch drm-fixes-4.1.
Comment 11 Lorenzo Bona 2015-07-04 22:31:37 UTC
Created attachment 181801 [details]
dmesg.log
Comment 12 Alex Deucher 2015-07-06 02:58:29 UTC
What are the pci ids of the audio devices on the GPU?  Does adding or updating your audio devices' entries in the hda driver like the following patch does help?

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=650474fb737c3e0ea0f6ab8e43c2cd161080ce5c
Comment 13 Lorenzo Bona 2015-07-06 05:29:00 UTC
(In reply to Alex Deucher from comment #12)
> What are the pci ids of the audio devices on the GPU?  Does adding or
> updating your audio devices' entries in the hda driver like the following
> patch does help?
> 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/
> ?id=650474fb737c3e0ea0f6ab8e43c2cd161080ce5c

PCI id is 1002:aab0 and is already in that file.
Line 2237 and 2238.
Comment 14 Lorenzo Bona 2015-07-10 22:10:38 UTC
Same issue on drm-fixes-4.2.
Comment 15 Lorenzo Bona 2015-07-13 05:47:53 UTC
I tried other sound settings but nothing can solve this issue.

BTW on my GPU playing a video is not enough, I need to run a game at least, the system needs a heavy load.
I've tried playing video with MPV and the sound is garbled too.

I've muted my OS sounds so I'm talking about garbled sound coming from MPV, iceweasel video (html5 only) and games.
Comment 16 Lorenzo Bona 2015-08-26 19:19:13 UTC
Any hint on this?
Comment 17 Alex Deucher 2015-08-26 22:00:30 UTC
Maybe something with the audio driver?  This doesn't seem to be a GPU driver issue.
Comment 18 Gerion 2015-09-15 15:19:46 UTC
I can reproduce this issue.

My card information:
01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde/Pitcairn HDMI Audio [Radeon HD 7700/7800 Series] [1002:aab0]
Comment 19 Tilman Sauerbeck 2015-11-21 11:08:27 UTC
FWIW, the size of the alsa device's prealloc buffer does seem to influence the magnitude of the problem on my Bonaire card.

I have been using the old default value of 64 for CONFIG_SND_HDA_PREALLOC_SIZE on this non-pulseaudio system. Bumping the size up to 2048 reduces the amount of noise a great deal.
Comment 20 Christian Birchinger 2016-01-30 22:31:19 UTC
The kernel documentation for CONFIG_SND_HDA_PREALLOC_SIZE has this:

Note that the pre-allocation size can be change dynamically via a proc file (/proc/asound/card*/pcm*/sub*/prealloc), too.

I don't have any "pcm" sub directories in /proc/asound/cardX. I have only this:

~ $ ls /proc/asound/card3
codec#0  eld#0.0  eld#0.1  eld#0.2  eld#0.3  eld#0.4  eld#0.5  id

I also couldn't find anything similar in /sys/class/sound. Is there still
a runtime config somewhere or am i forced to rebuild the kernel every time
to experiment with this?
Comment 21 Christian Birchinger 2016-03-23 19:17:03 UTC
I was under the impression, that i already gave feedback about the
"Pre-allocated buffer size" value, but i guess i did not.

Anyway, a value of 2048 seems to fix the issue. I've tried normal stereo,
DTS and DolbyD and the sound was fine and without dropouts.

So for me, the issue is solved and comment #17 is probably right too.
Comment 22 Alex Deucher 2016-03-23 19:58:19 UTC
This should be re-assigned to the audio driver then.
Comment 23 Andy Furniss 2016-03-23 22:18:49 UTC
I don't have a 270X anymore which I was using when first commenting in this bug.

My current R9285 Tonga also has this issue and I've just tried setting 2048 (runtime) for prealloc and it doesn't help me.

I do think this is a sound driver issue though as pulse audio works, though it was a different test = with fglrx the issue is also present when using alsa but not pulse.

The difference seems to be that alsa direct uses

SND_PCM_ACCESS_RW_INTERLEAVED

and via pulse it uses

SND_PCM_ACCESS_MMAP_INTERLEAVED
Comment 24 Gerion 2016-03-28 21:36:49 UTC
I tried a buffer size up to 8192, but is does not change anything.

Interesting fact is, that CPU load fixes the sound. As soon as I generate CPU load (e.g. compile something), the sound is more less normal.
Comment 25 haakobja 2016-04-27 18:45:10 UTC
I'm currently experiencing the same issue using a Radeon R9 270X. I've tried some of the tips discussed in the Arch Linux forums (https://bbs.archlinux.org/viewtopic.php?id=181764), but I've not been able to get it to work.

If I remember correctly, the driver bundled with the Radeon Catalyst-driver fixed the issue. Due to the recent kernel I'm running, the driver will not install. I'm currently running the 4.5.2-kernel.
Comment 26 Christian Birchinger 2017-03-24 00:56:18 UTC
Haven't used HDMI for almost a year now. The issue is still present and this time changing prealloc fixes nothing. 2048 used to work, but now all values i've tried from 64 to 4096 do nothing. The only thing that makes audio play normal is CPU load.
Comment 27 Gerion 2017-03-24 10:37:17 UTC
I've experienced a little more with CPU load and it seems, that not the CPU load is the essential part, but the memory access.

To be concrete:
stress -m 1
is enough to let the sound play normal,
stress -c X
results in load, but does not change the audio.
(I use this programm: http://people.seas.harvard.edu/~apw/stress/)
Comment 28 Andy Furniss 2017-03-24 11:22:01 UTC
Yea, I fount that you need io load, I use mprime - but not the test that just stresses cpu...

Of course using pulse, as most people do, avoids the bug as it uses sound different from alsa.

TODO - try and get jack to recreate what pulse does.

This is alsa -

andy@andy-desktop:~$ cat /proc/asound/card1/pcm3p/sub0/hw_params 
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 480
buffer_size: 11040

and pulse (well I didn't actually install pulse on my main LFS setup - but tested with a ubuntu boot - so maybe there are other differences).

access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 8192
buffer_size: 16384

I never had any luck playing with period/buffer size so I assume (possibly falsely) that the different access method is relevant.
Comment 29 Andy Furniss 2017-03-25 13:22:17 UTC
I tried with jack and it works - so I have another workaround.

It accesses alsa like -

cat /proc/asound/card*/pcm3p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 1024
buffer_size: 2048
Comment 30 lethalwp 2018-01-23 18:05:57 UTC
after discussing https://bugs.freedesktop.org/show_bug.cgi?id=101900
this bug seems to be still present in the amdgpu drivers.
When i have a cpuload, amdgpu sound is fine.
when the cpu is mostly idle, the sound is very glitchy.

So all RXxxx cards are affected.
Comment 31 Christian Birchinger 2018-05-18 18:16:18 UTC
Because you've referenced bug 101900 and the bug has been marked as fixed there, i've just retested my system with my now old Radeon R9 280X and Kernel 4.16.7

Audio over HDMI plays fine now. I've tested stereo and DTS passthru using mpv and sound is fine without any distortion regardless of system load.

Maybe a few others who still suffer from this issue want verify it too, but i think the bug seems fixed.
Comment 32 lethalwp 2018-05-31 07:09:51 UTC
It's still not ok for me with rx550 on a core2duo.
The HBR audio now starts playing to the audio receiver thanks to the fix.

But the sound is "flickering", it improves a lot by maximizing the audio buffer, and even more by putting load on the cpu(vm), but it's still not usable.

Couldn't reproduce this issue on a rx550+4770k. So it could be linked to older motherboards/cpus slower scheduling or something?

Iirc, i also tried an rxvega on the core2duo, couldn't reproduce it either.


I still have tests to do: retry it with another linux distro on the old computer. I really don't understand what or why anymore.
Comment 33 Christian Birchinger 2018-05-31 17:31:08 UTC
Seems like the issue was only gone because i've also played a video. With only the desktop open on the HDMI screen audio is still broken.
Comment 34 lethalwp 2019-03-23 08:27:04 UTC
retried on my ubuntu 18.04.02LTS + 'daily' kernel 4.20.0-999-generic #201812292101

+ kodi rx550 on core2duo

Sound now plays perfectly over HDMI, even HBR ones. Stutter is gone.


I don't know when it got fixed.
Comment 35 Christian Birchinger 2019-03-23 19:20:59 UTC
After a success report in the previous comment i've installed a 5.0.3 kernel
on my system.

The audio seems good so far. I'm trying to keep the load low in the background
to make sure this time it's not just fine because there's also a video playing.

It's been playing for 10 minutes without dropouts so far, i'm cautiously optimistic at this point (again).

If you have this problem and the possibility to test with a 5.0 kernel (or maybe 4.20 from the previous comment) give it a try please.

Note You need to log in before you can comment on or make changes to this bug.