I have so far not managed to get any HDMI audio from my TV via R9 285. I can get HDMI sound when connected to a monitor (with cpu load) With other h/w this TV has recently been OK with a bit of messing around eg. extra run of xrandr + cpu load for R9 270x. RS880 and rv770 worked without the cpu load. Added complication since getting a new mobo I sometimes get i2c edid read fails on the TV - but then it's not always and the rv770 produced them and worked and the tonga always works for sound with the TV in windows. I noticed that for the TV the eld does not match what edid decode reports - it only shows one sample rate and shows "Fl/Fr C" when it's only 2 channel. TBH I don't know what eld said historically with different h/w. edid-decode and eld for TV attached.
Created attachment 117191 [details] Patch to add tonga audio pciid Forgot to say - the behavior is the same with or without my audio pciid added to kernel. Of course I don't know if the patch is right for amdgpu h/w (I did also test without the _NS but it made no difference).
Created attachment 117192 [details] Tv edid decode I checked "Linear PCM, max channels 1" and it's an edid-decode issue the specs say it's stored -1 and the edid-decode code just reports what's in the data when it should really add one.
Created attachment 117193 [details] TV - eld
Another difference I notice between TV and monitor. Results playing the same file in the same (well sort of I guess) mode. If I poll the status like while true do cat /proc/asound/card*/pcm3p/sub0/status sleep 1 done I notice the TV has a different trigger time (what ever that is!) from the working monitor. TV = hw_ptr : 3248362 appl_ptr : 3260160 state: RUNNING owner_pid : 711 trigger_time: 8886.763851145 tstamp : 0.000000000 delay : 11721 avail : 279 avail_max : 279 monitor = hw_ptr : 1137764 appl_ptr : 1149600 state: RUNNING owner_pid : 493 trigger_time: 2439.504907490 tstamp : 0.000000000 delay : 11643 avail : 357 avail_max : 357 I'll attach edid and eld from monitor.
Created attachment 117197 [details] monitor eld
Created attachment 117198 [details] monitor edid-decode
(In reply to Andy Furniss from comment #4) > Another difference I notice between TV and monitor. > I notice the TV has a different trigger time (what ever that is!) from the > working monitor. Hmm well more messing around shows the it's variable on the monitor just got - trigger_time: 5550.580103154
Created attachment 117268 [details] tv eld ubuntu fglrx I do get sound from the TV with ubuntu 15.04 and fglrx (with cpu load). The eld still doesn't quite match eded-decode as only 16 is listed as sample size but it is different from my OSS setup in that it just lists speakers [0x1] FL/FR rather than the eronious extra "C" in the tv - eld I previously attached.
Created attachment 117279 [details] debug/test diff I played a bit more round this eld thing and it seems there is a bug - but it looks like it's the same for older radeon dce as well, and "fixing" it doesn't get me sound on the TV - it does of course make /proc/asound eld look saner. The difference between my monitor and the TV is that the monitor has a speaker layout block and the TV doesn't. So the monitor hits the the "if" in the attached diff and the value of sadb[0] is 1. The TV hits the else and gets allocated a value of 5 which is commented as stereo, but according to the edid sections of CEA B and D stereo is 1 and 5 is just like I see in /proc/asound Fl/Fr Fc.
(In reply to Andy Furniss from comment #9) > I played a bit more round this eld thing and it seems there is a bug Of course it's not a bug at all if you read FL/FR FC as stereo OR mono ... Whatever it seems to be nothing to do with the issue here anyway.
-- 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/53.
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.