Bug 86351
| Summary: | HDMI audio garbled output on Radeon R9 280X | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Christian Birchinger (joker) |
| Component: | Video(DRI - non Intel) | Assignee: | drivers_video-dri |
| Status: | NEW --- | ||
| Severity: | normal | CC: | adf.lists, alexdeucher, gerion-kernel, haakobja, jorg.heijnis, lethalwp, szg00000, tilman |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 3.17 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
dmesg output
lsmod output asound /proc info dmesg.log |
||
Created attachment 153901 [details]
lsmod output
Created attachment 153911 [details]
asound /proc info
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. You are not alone, I get this on my R9270X - https://bugs.freedesktop.org/show_bug.cgi?id=77677 Does forcing the GPU clocks to high help? E.g., as root: echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level (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. If you are using CPU governor, does forcing the CPU power state to a stable state help? (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. "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. 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. Created attachment 181801 [details]
dmesg.log
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 (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. Same issue on drm-fixes-4.2. 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. Any hint on this? Maybe something with the audio driver? This doesn't seem to be a GPU driver issue. 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] 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. 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? 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. This should be re-assigned to the audio driver then. 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 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. 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. 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. 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/) 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. 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 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. 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. 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. 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. 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. 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. |
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.