Posts by jernej

freenix Can you this one: LibreELEC-A64.arm-9.80-devel-20200805221609-bd5130b-orangepi-win.img.gz

It's with kernel 5.8 which didn't yet landed in LE master branch, but it works for me...

Quote from alzinzav

No more images for A20. It's normal?

I opened PR with a build fix. A20 nightly images will be available again after it is merged. Thanks for notification.

Did you check Audio passthrough testing ?

yeah, 3D mode is not implemented, I don't have 3D display...

Thanks! Unfortunately, there is one bug which prevents merging these changes to master branch - if display refresh rate is set below deinterlacing speed (usually 50 - 60 fps) then video will start lacking behind audio. I have yet to figure out what to fix in Kodi.

FYI, next nightly will also have VP8 HW decoding support.

Lewis Changes were already merged few hours ago so next nightly image should have all fixes. Anyway, I'm still interested if it works for you or not.

I only added kernel and alsa-lib changes in order to enable it so probably Kodi doesn't have PT implemented for audio only files. I don't really know Kodi audio subsystem in order to check or implement that. I suggest you ask at Kodi forum.

Note, after some more testing, it seems to work reliably only when screen resolution is set at 1080p @ 60 Hz for me.

Lewis Please test this update: LibreELEC-H3.arm-9.80-devel-20200719123645-ddd7a12-drmfix.tar

it should fix disappearing menu and green screens in all configurations.

No, nothing is merged yet, but I have working patch already. I probably also discovered reason for green frames - also DRM driver issue. I didn't know about these issues because I always tested on 4k @ 30 Hz where it seems to work fine. However, if I switch to 1080p @ 60 Hz, then I'm able to reproduce these two issues quiet easily.

Lewis I reproduced the issue and I already know what is the problem. I'll take a look how to properly fix it in following days, but for quick fix you can execute:

devmem 0x01100800 w 0x301
devmem 0x01100008 w 1

during playback, when issue appears.

I played a bit with various flags in DT but nothing helps to restore speed. I have a feeling that H6 mmc driver is not optimized but I have no idea about it. Since it works for you I won't spend much time on it for now. Anyway, PR for PineH64 eMMC support would be welcome. If you don't want to do it, I can take a shoot sometime in future.

EDIT: So I did same speed on Android where I got ~130 MiB/s so definitely driver issue.

ha, on Tanix TX6 I get without mmc-hs400-1_8v

/dev/mmcblk1:
 HDIO_DRIVE_CMD(identify) failed: Invalid argument
 Timing buffered disk reads: 244 MB in  3.01 seconds =  81.15 MB/sec

and with mmc-hs400-1_8v

/dev/mmcblk1:
 HDIO_DRIVE_CMD(identify) failed: Invalid argument
 Timing buffered disk reads: 132 MB in  3.01 seconds =  43.92 MB/sec

so this for some reason halves access read speed...

roel No need to read markings, I got info that I need from Odroid page. In your case mmc-hs400-1_8v; would be more correct.

Can you make read speed test with hdparm? I forgot exact command but I know you should make non-buffered test, otherwise read speed will be much too high.

roel Are you using actual Odroid emmc module or that from Pine64. If it is that from Pine64 (ncembsf9-16g) then mmc-hs200-1_8v; should be enough. Can you test that? If it has some other eMMC chip, can you please post markings here?

roel can you share diff between mainline and modified DT? You or genidy.m can send patch to upstream Linux for inclusion.

serafis Great job! That's really helpful. So it turns out there is (are) issue(s) with HDMI and/or clock configuration for particular resolution. It makes sense that could be a problem. Audio packets are sent in blanking intervals between two consecutive frames. If this timing is off then there could be also audio issues. Can you please provide output of edid-decode /sys/class/drm/card0-HDMI-A-1/edid? This should tell what timings are communicated by your TV and AVR. I just tested 1360x768p @ 60 Hz on my TV and everything seems to work fine. I suspect that my TV is pretty forgiving for non-optimal configurations.

Regarding multi-channel configuration - I noticed that same format (iec958) is used also for non-passthrough (linear PCM) audio. This shouldn't be the case, so ALSA config needs some changes.

serafis can you test with software decoding? One issue found on RPi4 is that HW decoding and audio passthrough don't play well along.