Created attachment 97618 [details] Alsa No Pulseaudio xorg.0.log dmesg aplayL/l codec logs I am having issues playing sounds over HDMI stereo directly to TV. I am using XBMC. When Pulse Audio is installed the sounds play fine in stereo. When I try a pure alsa installation (no pulse audio) there is severe distortion. Pure ALSA is needed for applications that only support ALSA, and for HDMI pass-through. My dedicated Radeon 7750 card only outputs cyclical sounds, quiet voices like wrong channel, and echos. Setup PC to TV directly HDMI (2.0 audio selected). I have had the same issue when cpu was an AMD 955BE, and now Intel i7 4770. Windows 7 plays hdmi audio just fine on the same exact PC/Panasonic plasma/setup. 1) speaker-test -l 4 -c 2 -r 48000 -D hw:1,3 plays choppy sounds with or without pulse installed. 2) aplay -D plughw:1,3 /usr/share/sounds/alsa/Front_Center.wav plays fine Using an A4-3400 HDMI plays perfectly fine on the same TV. As does my Zotac AQ01. Not sure if this is related (http://ubuntuforums.org/showthread.php?t=2207698): SND_PCM_ACCESS_RW_INTERLEAVED vs. SND_PCM_ACCESS_MMAP_INTERLEAVED I believe XBMC uses SND_PCM_ACCESS_RW_INTERLEAVED for ALSA. Thanks in advance.
Created attachment 97619 [details] Pulseaudio xorg.0.log dmesg aplayL/l codec logs Same logs for Pulse Audio installation.
Created attachment 97620 [details] mp3 of distorted HDMI sounds MP3 recording of sounds. It is machine gun like sometimes.
Created attachment 97621 [details] Alsa No Pulseaudio xorg.0.log dmesg aplayL/l codec logs retry attached as binary this time.
Possibly a duplicate of bug 77002. Does the fix mentioned in that bug help?
(In reply to comment #4) > Possibly a duplicate of bug 77002. Does the fix mentioned in that bug help? Thanks. But no, unfortunately. I tested the reverse order patch (on 77002). I believe it may be part of my kernel 3.14.1testing patched by Fritsch/Peter for the PLL/24P optimizations (which works great BTW). Trusty release default kernel 3.13 displayed the same behavior. I noticed that there were 2 patches (77002). I only tried the reverse order patch. Did you want me to test your patch? Please let me know if I can provide anything. I know of an ATI 7870 that also is affected (in case it helps). I have been trying to help another XBMC user on OpenElec (it uses pure ALSA). I am going to get a new HDMI AVR today. So I can further test 5.1 HDMI audio, too, if needed. thanks, Garrett
Please reproduce with a mainline kernel. It's not really a good idea to find regressions, when it's not fully clear which patches are integrated. Additionally the 3.14.1 kernel that I build, includes a non gpl module to drive Ngene dvb-c adapters. Please try 3.14.1 or a 3.15-rcX (it's clear that the PLL work is not in there - but currently you are tracking down Audio issues).
Created attachment 97650 [details] dmesg 3.15rc2 Mainline Kernel ALSA only has problem still @Peter. Thanks. That makes perfect sense. Sorry about that. I just installed this from mainline. 3.15rc2. It is still affected. ALSA distortion over HDMI.
Created attachment 97651 [details] xorg.0.log 3.15rc2 affected
Created attachment 97652 [details] aplay -L 3.15rc2 affected
i too suffer from this issue. it's been going on for me as you will see from my log since kernel 3.13 i'm posting my XBMC log file since this is the only thing that I run on my system. My situation is a little different. with my system, the sound will be fine. Even certain streams will play just fine for a while. then when something "interrupts" the stream, I start to get the distortion/ echoing sounds. this is both audio and video streams. sometimes I can play a 30 minute clip, and never get it. other times it will start to happen in the first 5 minutes. i have been wondering about ways to increase the buffer size / period size. but have not had any luck. I have also not tried PA as an option to see if it "fixes" the problem.
Created attachment 97757 [details] old XBMC log file I will try to get you more logs. i will need to load on a mainline kernel first.
.... @fritsch, is the kernel you posted on the XBMC forum -- 3.14.1-amdfixes2 considered "mainline"?
No. And one note here: This is not xbmc forum. We are so kind there (cause we have too much time), that we sort out "different issues" and codrivers. This here is an official bugtracker. Every mail is forwarded to the Mailinglist. So please, don't spam Christian and Alex. Your bug is fundamentally different as you already have noted. So please, don't post "me toos" into a bugreport which has some activity.
*** Bug 77898 has been marked as a duplicate of this bug. ***
Created attachment 97960 [details] aplay -L
Created attachment 97961 [details] dmesg
Created attachment 97962 [details] Xorg.0.log
[AMD/ATI] Richland [Radeon HD 8470D] thought it might be convenient to post my logs to this thread since it seems it is a duplicate.
I've just changed my HD4890 for a R9 270x, which is roughly AIUI a 7870 and have hit this issue. Testing with mplayer I do have some differences, but would probably get duped if I posted a new bug so - Kernels tested drm-fixes - 3.15.0-rc2-41381-gabaafc0 3.13.0-rc6-14283-g61ef8be 3.12.0-rc7-01267-g3d3b78c Both working and non working cases show the same alsa h/w params which is the same as my old card which always worked eg. access: RW_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 1024 buffer_size: 16384 With mplayer as long as there is video it seems to work OK (20 mins longest test so far). Pure audio files or "working" video played with -vc null always fail and sound like the mp3. -vo null without -vc null always works OK. Only s/w decode works, UVD will produced trashed sound, so if that's the default for xbmc it could be something worth testing.
(In reply to comment #19) > With mplayer as long as there is video it seems to work OK (20 mins longest > test so far). This turned out not to be correct - I was testing with HD video and they do work - but SD will fail. I posted to the mplayer list and one of the devs thought it sounded like a reclocking issue and suggested I try playing audio while running glxgears. With vblank_mode=0 it does help but not totally cure, the audio progresses normally as opposed to being mostly stuck, but is still distorted. Running a nexuiz timedemo, however totally cures it! So it seems that loading up my system is the way to fix and why my HD vids worked but failed with UVD. I have tried disabling cpufreq on_demand and also forcing dpm auto/low/high, but there is no difference - I need load to make it work.
As a workaround, use xbmc and whenever you upscale a video, choose Lanczos3 Optimized as Scaling algorithm. That should put a whole lot of pressure onto the GPU. Make sure to not use that one to "upscacle" 1080 to 1080, cause that will kill performance.
*** Bug 78235 has been marked as a duplicate of this bug. ***
This might be a duplicate of bug 76837. Does disabling dpm help? Append radeon.dpm=0 to the kernel command line in grub.
(In reply to comment #23) > This might be a duplicate of bug 76837. Does disabling dpm help? Append > radeon.dpm=0 to the kernel command line in grub. dpm=0 doesn't help me.
(In reply to comment #20) > I have tried disabling cpufreq on_demand and also forcing dpm auto/low/high, > but there is no difference - I need load to make it work. Been playing more - it seems to be CPU load that I need not GPU. I can reproduce the issue playing audio without X started from fbcon. make -j5 &>/dev/null on mesa from another fbcon will make the sound OK. While I've got rid of cpufreq on_demand I haven't yet managed to stop acpi_cpufreq loading, though of course it may be innocent - no issues with the same setup with my 4890.
Maybe some power saving feature in the hda driver?
(In reply to comment #23) > This might be a duplicate of bug 76837. Does disabling dpm help? Append > radeon.dpm=0 to the kernel command line in grub. after some initial testing of different sources, this does seem to help me. I will continue to test through the week, and let you know if the sound returns. so far, so good.
(In reply to comment #26) > Maybe some power saving feature in the hda driver? My mobo sound doesn't have any problems, it's just hdmi, anyway it seems like 0 is in my kernel config, but I also tried snd_hda_intel power_save=0 but no luck. I also tried several other things but none worked, I did get rid of acpi_cpufreq. snd_hda_intel position_fix=1 and 2, and after noticing my mobo sound wasn't using msi but radeon was I disabled that, but it didn't help. Also tried single_cmd=1, but got no sound at all with that (mobo sound still worked). Attaching dmesg.
Created attachment 98581 [details] Andy Furniss dmesg
after continued testing through the week, I have not had any sound distortions. The addition of radeon.dpm=0, in my kernel command line in grub, has seemed to eliminate the problem.
(In reply to comment #23) > This might be a duplicate of bug 76837. Does disabling dpm help? Append > radeon.dpm=0 to the kernel command line in grub. Adding radeon.dpm=0 to boot params did not work. I am sorry to report. On my 7750 card. HDMI sound is machine gun like, still in Openlec.
"Only s/w decode works, UVD will produced trashed sound, so if that's the default for xbmc it could be something worth testing." I tested software decode (disabling all vdpau) in Openelec (XBMC) and it works perfectly. Sound and picture is perfect. radeon.dpm=0 still. Let me know if you need anything else
I have this issue using both Software and Hardware decoding on XBMC. It is MUCH worse when using VDPAU and glamor HW acceleration, but is present with SW-only acceleration. I have an AMD Sapphire Redeon HD7750 with an Intel i3 running 3.15.3 kernel and a git build (via mesa-git on Arch) of Mesa, libgl and ati-dri.
-- 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/489.
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.