Bug 77002 - hdmi audio problems with 3.14
Summary: hdmi audio problems with 3.14
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
: 77274 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-04-03 13:23 UTC by bgunteriv
Modified: 2015-01-22 16:13 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg (67.42 KB, text/plain)
2014-04-03 13:23 UTC, bgunteriv
no flags Details
Xorg.0.log (51.41 KB, text/plain)
2014-04-03 13:25 UTC, bgunteriv
no flags Details
vdpauinfo (2.71 KB, text/plain)
2014-04-03 13:26 UTC, bgunteriv
no flags Details
mesa (1.26 KB, text/plain)
2014-04-03 13:27 UTC, bgunteriv
no flags Details
good_dmesg-kernel 3.13.8 (63.51 KB, text/plain)
2014-04-04 15:29 UTC, bgunteriv
no flags Details
xbmc trying to play video/audio files (257.46 KB, text/plain)
2014-04-04 15:35 UTC, bgunteriv
no flags Details
workaround (1.77 KB, patch)
2014-04-07 02:26 UTC, Alex Deucher
no flags Details | Splinter Review
dmesg - kernel 3.14 w/ patch (66.98 KB, text/plain)
2014-04-07 15:33 UTC, bgunteriv
no flags Details
ALSA: hda - Do not assign streams in reverse order (1.82 KB, patch)
2014-04-07 19:42 UTC, Anssi Hannula
no flags Details | Splinter Review
debug logs of hdmi audio distortion with reverse order patch (13.38 KB, application/octet-stream)
2014-04-09 14:30 UTC, Garrett
no flags Details
mp3 of distorted HDMI sounds (237.00 KB, application/octet-stream)
2014-04-09 14:35 UTC, Garrett
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description bgunteriv 2014-04-03 13:23:29 UTC
Created attachment 96846 [details]
dmesg

not sure where this bug belongs.

having great issues with the new kernel 3.14 on my system trying to play any type of media -- video or music.

currently running kernel 3.13 version 8. is the most stable.

here are my logs when running kernel 3.14
dmesg | pastebinit
http://paste.ubuntu.com/7033651/
cat ~/.xbmc/temp/xbmc.log | pastebinit
http://paste.ubuntu.com/7033687/
cat /var/log/Xorg.0.log | pastebinit
http://paste.ubuntu.com/7033653/
DISPLAY=:0 vdpauinfo | pastebinit
http://paste.ubuntu.com/7033656/
dpkg -l |grep mesa | pastebinit
http://paste.ubuntu.com/7033657/

and here's a log file when trying to play a video... both online, and from my hard drive. and a music file (which made XBMC freeze):
http://paste.ubuntu.com/7033704/

and yes. i get the same results when running the most recent "stable" version of the kernel 3.14. but can try to get some logs if necessary.
Comment 1 bgunteriv 2014-04-03 13:25:11 UTC
Created attachment 96847 [details]
Xorg.0.log
Comment 2 bgunteriv 2014-04-03 13:26:30 UTC
Created attachment 96848 [details]
vdpauinfo
Comment 3 bgunteriv 2014-04-03 13:27:13 UTC
Created attachment 96849 [details]
mesa
Comment 4 bgunteriv 2014-04-04 14:44:18 UTC
please let me know if you require some different information.
Comment 5 Alex Deucher 2014-04-04 14:48:58 UTC
What sort of issues are you having?  Display corruption?  gpu hangs?  system hangs?  Is this a regression?  If so, when did it last work?
Comment 6 bgunteriv 2014-04-04 15:28:53 UTC
oh! my apologies, i guess i left that out.

i'm seeing choppy video, no audio at all.
audio files don't play.
using HDMI output. I have not tried S/PDIF
I'm using XBMC as my interface with minimal install of Ubuntu.

I would say regression.
all 3.13.x kernels work for me.
I've noticed this problem with the very first introduction of kernel 3.14.rc1

i'll attach a good dmesg. with my current kernel 3.13.8
Comment 7 bgunteriv 2014-04-04 15:29:37 UTC
Created attachment 96906 [details]
good_dmesg-kernel 3.13.8
Comment 8 bgunteriv 2014-04-04 15:35:43 UTC
Created attachment 96908 [details]
xbmc trying to play video/audio files

Here is the last file of my original post as an attachment. i forgot to upload this the first time.

Getting a lot of I/O errors in AlSA Sink.
Comment 9 bgunteriv 2014-04-05 21:43:43 UTC
does the information i gave you help?
or do you need further explanation?
Comment 10 Alex Deucher 2014-04-07 02:20:04 UTC
Does reverting 832eafaf34ff7d0348fe701e417900c6cf1f5656 help?
Comment 11 Alex Deucher 2014-04-07 02:26:25 UTC
Created attachment 97008 [details] [review]
workaround

Does that attached kernel patch fix the issue?
Comment 12 bgunteriv 2014-04-07 15:33:05 UTC
(In reply to comment #11)
> Created attachment 97008 [details] [review] [review]
> workaround
> 
> Does that attached kernel patch fix the issue?

no this did not help.
also, now when it boots up, I get the message:
drm:module has bad taint, not creating trace events

i'm attaching new dmesg.
Comment 13 bgunteriv 2014-04-07 15:33:55 UTC
Created attachment 97042 [details]
dmesg - kernel 3.14 w/ patch
Comment 14 Alex Deucher 2014-04-07 15:35:32 UTC
Does reverting 832eafaf34ff7d0348fe701e417900c6cf1f5656 help?
Comment 15 bgunteriv 2014-04-07 19:13:40 UTC
(In reply to comment #14)
> Does reverting 832eafaf34ff7d0348fe701e417900c6cf1f5656 help?

no, this did not help either.
just to make sure i did this correctly.
i got the git from here --> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
and then i ran:
git revert 832eafaf34ff7d0348fe701e417900c6cf1f5656

it said that it did it...

after updating the kernel, i still saw that message about:
drm:module has bad taint, not creating trace events
Comment 16 Anssi Hannula 2014-04-07 19:22:35 UTC
It seems to be https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7546abfb8e1f9933b549f05898377e9444ee4cb2
+ the fact streams are assigned in reverse order.

I'll have a patch for reversing the assignment shortly.

Alex, is the limit 4 streams on 7-output cards as well, or is it just these 1-output cards only?
Comment 17 Alex Deucher 2014-04-07 19:39:55 UTC
(In reply to comment #16)
> It seems to be
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/
> ?id=7546abfb8e1f9933b549f05898377e9444ee4cb2
> + the fact streams are assigned in reverse order.
> 
> I'll have a patch for reversing the assignment shortly.
> 
> Alex, is the limit 4 streams on 7-output cards as well, or is it just these
> 1-output cards only?

What do you mean by 4 streams?  Is that the same as audio pins?
Comment 18 Anssi Hannula 2014-04-07 19:42:48 UTC
Created attachment 97049 [details] [review]
ALSA: hda - Do not assign streams in reverse order

Please try this one.
Comment 19 Anssi Hannula 2014-04-07 19:46:43 UTC
(In reply to comment #17)
> (In reply to comment #16)
> > It seems to be
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/
> > ?id=7546abfb8e1f9933b549f05898377e9444ee4cb2
> > + the fact streams are assigned in reverse order.
> > 
> > I'll have a patch for reversing the assignment shortly.
> > 
> > Alex, is the limit 4 streams on 7-output cards as well, or is it just these
> > 1-output cards only?
> 
> What do you mean by 4 streams?  Is that the same as audio pins?

AFAIK this is the maximum amount of different streams played back at once. 
Before the patch I just attached, ALSA always used the "stream numbers" starting from the last one, which caused problems with assumed 8 streams because Christian's card only had 4 streams (his card had a single output only, though; alsa-info: http://sprunge.us/dbiB ).

So in addition to the patch I just attached I think we need to correct the stream count, _IF_ the 6/7-output cards only have 4 streams as well. But if those cards support 6/7 streams as well, all is OK.
Comment 20 Anssi Hannula 2014-04-07 19:49:05 UTC
Sorry, and by "outputs" I mean "pins".
Comment 21 Anssi Hannula 2014-04-07 20:14:33 UTC
(In reply to comment #19)
> maximum amount of different streams played back at once.

Well streams can be inactive as well, so this was not entirely accurate... See Section 2.2 of HDA spec for what a stream is in this context.

What I'm after is the correct value for HDA spec 3.3.2, register offset 00h, bits 12-15 (Number of Output Streams Supported (OSS)), which is 0x00 (no audio output streams) on the AMD cards for some reason.

For Christian's card the correct value seems to be 4, but I wonder if the same is true for 6/7-pin cards as well or if they have it at least 6/7 so there are streams for every pin available. If (streams >= pins) is true always, I think there is no need to add any other fixes.
Comment 22 Alex Deucher 2014-04-07 20:14:44 UTC
(In reply to comment #19)
> (In reply to comment #17)
> > 
> > What do you mean by 4 streams?  Is that the same as audio pins?
> 
> AFAIK this is the maximum amount of different streams played back at once. 
> Before the patch I just attached, ALSA always used the "stream numbers"
> starting from the last one, which caused problems with assumed 8 streams
> because Christian's card only had 4 streams (his card had a single output
> only, though; alsa-info: http://sprunge.us/dbiB ).
> 
> So in addition to the patch I just attached I think we need to correct the
> stream count, _IF_ the 6/7-output cards only have 4 streams as well. But if
> those cards support 6/7 streams as well, all is OK.

Kaveri:                4 streams, 7 endpoints
Kabini:                2 streams, 3 endpoints
Bonaire/Hawaii:        6 streams, 7 endpoints
Trinity/Richland:      4 streams, 6 endpoints
Oland:                 2 streams, 2 endpoints
Tahiti/Pitcairn/Verde: 6 streams, 6 endpoints

Endpoints would be equivalent to pins as I understand it.
Comment 23 Takashi Iwai 2014-04-08 07:37:37 UTC
I'd rather revert the commit in this case.  Changing the assignment order has a significant risk of breakage with other weird controllers.

Could you confirm that just reverting the commit fixes the problem?  Once after it's confirmed, I'll submit a fix revert patch for 3.14.x.  Thanks.
Comment 24 bgunteriv 2014-04-08 13:10:54 UTC
(In reply to comment #23)
> I'd rather revert the commit in this case.  Changing the assignment order
> has a significant risk of breakage with other weird controllers.
> 
> Could you confirm that just reverting the commit fixes the problem?  Once
> after it's confirmed, I'll submit a fix revert patch for 3.14.x.  Thanks.

The patch worked... reverting did not.
although, again, i'm not positive i've done it correctly.

if you read my post above, it explains my steps. 
if i did it correctly, then no, reverting does not solve the problem.

I do see warnings when my system boots up about:
bad taints
in both drm and kvm modules.
Comment 25 Anssi Hannula 2014-04-08 17:42:02 UTC
(In reply to comment #24)
> (In reply to comment #23)
> > I'd rather revert the commit in this case.  Changing the assignment order
> > has a significant risk of breakage with other weird controllers.
> > 
> > Could you confirm that just reverting the commit fixes the problem?  Once
> > after it's confirmed, I'll submit a fix revert patch for 3.14.x.  Thanks.
> 
> The patch worked... reverting did not.
> although, again, i'm not positive i've done it correctly.
> 
> if you read my post above, it explains my steps. 
> if i did it correctly, then no, reverting does not solve the problem.

Note that Takashi was talking about the commit in comment #16, note the one you reverted previously. Can you verify you reverted the correct patch?

If my patch fixed your issue, it would be unexpected that reverting would not work as well.
Comment 26 bgunteriv 2014-04-08 18:07:20 UTC
(In reply to comment #25)

> Note that Takashi was talking about the commit in comment #16, note the one
> you reverted previously. Can you verify you reverted the correct patch?
> 
> If my patch fixed your issue, it would be unexpected that reverting would
> not work as well.

ah! i see. okay i will try that and let you know.
Comment 27 bgunteriv 2014-04-08 20:53:09 UTC
(In reply to comment #26)
> (In reply to comment #25)
> 
> > Note that Takashi was talking about the commit in comment #16, note the one
> > you reverted previously. Can you verify you reverted the correct patch?
> > 
> > If my patch fixed your issue, it would be unexpected that reverting would
> > not work as well.
> 
> ah! i see. okay i will try that and let you know.

yes. reverting this commit -- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7546abfb8e1f9933b549f05898377e9444ee4cb2

did work as well.
thanks everyone.

let me know if you need me to test anything else going forward.
Comment 28 Garrett 2014-04-09 14:30:39 UTC
Created attachment 97137 [details]
debug logs of hdmi audio distortion with reverse order patch

Hi,
Hope that this is the correct place.  Let me know if you wish for me to open a new bug report.

I'm using an Openelec git pulled local build- so that I can test patches (w/wo reverse order patch from this thread): 

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.  

TIA.
Garrett
Comment 29 Peter Frühberger 2014-04-09 14:32:34 UTC
Garret,

make sure your tree is in sync. The patch done by Anssi has already been included. It's here: https://github.com/OpenELEC/OpenELEC.tv/commit/a333166f7d6fda668cc2184797d302fe89288c9d
Comment 30 Garrett 2014-04-09 14:35:28 UTC
Created attachment 97138 [details]
mp3 of distorted HDMI sounds

mp3 of playing a video with the HDMI sound distortion from TV speakers.
Comment 31 bgunteriv 2014-04-09 14:40:32 UTC
(In reply to comment #29)
> Garret,
> 
> make sure your tree is in sync. The patch done by Anssi has already been
> included. It's here:
> https://github.com/OpenELEC/OpenELEC.tv/commit/
> a333166f7d6fda668cc2184797d302fe89288c9d

make sure you read the comments about what Takashi Iwa wrote (comment #23)
i'm not sure how this will change things.
----------quote-------------------------
I'd rather revert the commit in this case.  Changing the assignment order has a significant risk of breakage with other weird controllers.

Could you confirm that just reverting the commit fixes the problem?  Once after it's confirmed, I'll submit a fix revert patch for 3.14.x.  Thanks.
-----------quote------------------------

@Garrett, are you @gfisher on the XBMC forums?
if so, I'm not sure if this is the same issue. I was having problems with the new kernel working with my OS. this did not solve my problem. I think we'll have to create a new bug report for that one.
let me know on the XBMC forum if this did clear your problem... would be very interesting.
Comment 32 Garrett 2014-04-09 15:13:46 UTC
Yes I am gfisher.  

Peter.  OK. I renamed/saved the old pull.  I git pulled new.  I will rebuild overnight.  Thx.

The logs that I upload- I applied this patch https://bugs.freedesktop.org/attachment.cgi?id=97049&action=edit to kernel 3.14 in the oe build.  According to the messages it patched ...hda just fine.  It did not appear to change anything (bug wise).  I did the logs in #29 over SSH while the sounds were distorted.

I saw the revert commit comment.  But I am not sure that I can do that on an OE system (I managed to get patches to work).  I am using OE because breakage and testing across PC is so much easier.

I will rebuild the latest OE 4.0 branch from new, then report back.  Let me know if anything else is needed.
Comment 33 bgunteriv 2014-04-09 15:22:57 UTC
Garrett,
the part about reverting and patching was actually meant for Peter.

----------------------------------------

Peter,

It sounds like Takashi Iwai (comment #23)
is looking to go another direction to fix the problem with the kernel commit (7546abfb8e1f9933b549f05898377e9444ee4cb2), as opposed to just patching it.

hopefully he can shed more light on this subject...

as I said. the patch works... but also reverting the commit on the original kernel also works.
Comment 34 Garrett 2014-04-10 14:21:13 UTC
(In reply to comment #29)
> Garret,
> 
> make sure your tree is in sync. The patch done by Anssi has already been
> included. It's here:
> https://github.com/OpenELEC/OpenELEC.tv/commit/
> a333166f7d6fda668cc2184797d302fe89288c9d

OK the build finished this AM and in the linux/3.14 folder this reverse-order patch was present.  But unfortunately playback is the same.  Machine gun like cyclical sounds with audio coming in and out.

Any more info needed, please let me know.

Here is my card [Diamond 7750PE51G]:

http://www.newegg.com/Product/Product.aspx?Item=N82E16814103206

thanks,
Garrett
Comment 35 bgunteriv 2014-04-10 14:28:30 UTC
(In reply to comment #34)
> (In reply to comment #29)
> > Garret,
> > 
> > make sure your tree is in sync. The patch done by Anssi has already been
> > included. It's here:
> > https://github.com/OpenELEC/OpenELEC.tv/commit/
> > a333166f7d6fda668cc2184797d302fe89288c9d
> 
> OK the build finished this AM and in the linux/3.14 folder this
> reverse-order patch was present.  But unfortunately playback is the same. 
> Machine gun like cyclical sounds with audio coming in and out.
> 
> Any more info needed, please let me know.
> 
> Here is my card [Diamond 7750PE51G]:
> 
> http://www.newegg.com/Product/Product.aspx?Item=N82E16814103206
> 
> thanks,
> Garrett

this was my fear. I don't think your problem fits the scope of this bug.

Garrett, can you open a new bug report, and i'll put up my logs as well. 
this way we won't get the devs confused on this situation.
send me a PM on XBMC once you've got it.
Comment 36 Alex Deucher 2014-04-11 13:06:20 UTC
*** Bug 77274 has been marked as a duplicate of this bug. ***
Comment 37 bgunteriv 2015-01-21 18:31:48 UTC
I feel like this issue has come back again...

the only problem is that I can not find when it started back up.

I've been following the developments of the kernels from 3.14, all the way to 3.19rc1,
and I just started noticing it.

I have also just recently been following the development of Mesa 10.5(devel).
so, i don't know if that's the culprit.

I will spend some time this week to try and test as many kernels as I can.
Comment 38 bgunteriv 2015-01-22 16:13:48 UTC
reclosing this, as I see it might be related now to this https://bugs.freedesktop.org/show_bug.cgi?id=77677


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.