Bug 77002

Created attachment 96847 [details]
Xorg.0.log

Created attachment 96848 [details]
vdpauinfo

Created attachment 96849 [details]
mesa

please let me know if you require some different information.

What sort of issues are you having?  Display corruption?  gpu hangs?  system hangs?  Is this a regression?  If so, when did it last work?

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

Created attachment 96906 [details]
good_dmesg-kernel 3.13.8

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.

does the information i gave you help?
or do you need further explanation?

Does reverting 832eafaf34ff7d0348fe701e417900c6cf1f5656 help?

Created attachment 97008 [details] [review]
workaround

Does that attached kernel patch fix the issue?

(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.

Created attachment 97042 [details]
dmesg - kernel 3.14 w/ patch

Does reverting 832eafaf34ff7d0348fe701e417900c6cf1f5656 help?

(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

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?

(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?

Created attachment 97049 [details] [review]
ALSA: hda - Do not assign streams in reverse order

Please try this one.

(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.

Sorry, and by "outputs" I mean "pins".

(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.

(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.

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.

(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.

(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.

(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.

(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.

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

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

Created attachment 97138 [details]
mp3 of distorted HDMI sounds

mp3 of playing a video with the HDMI sound distortion from TV speakers.

(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.

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.

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.

(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

(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.

*** Bug 77274 has been marked as a duplicate of this bug. ***

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.

reclosing this, as I see it might be related now to this https://bugs.freedesktop.org/show_bug.cgi?id=77677