| Bug ID | 91371 |
|---|---|
| Summary | Tonga HDMI Audio none on TV working on monitor - possible eld issue |
| Product | DRI |
| Version | DRI git |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | DRM/AMDgpu |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | adf.lists@gmail.com |
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.
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.
(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.
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | MOVED |
-- 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.