[wrxtasy]

As I am seriously thinking of getting one of these boxes to replace my aging HTPC that I built 3 years ago what skin is everyone using. I would really like to use the Aeon MQ 5 or 6 skin as i have been using this for years and really love it, how smooth and responsive is it as i installed MQ5 on my mates wetek play and it was just laggy. Any advice would be much appreciated

Got around to testing Aeon Nox 5 Redux with WeTek Jarvis RC3 mediaplayer. There have been a few tweaks that have gone into this version of WeTek Jarvis and this Skin is not laggy at all, in fact its pretty snappy with all the Blingy Artwork to boot

The Android Lollipop 5.1.1 OS is a whole different beastie compared to the previous KitKat. Google have done a bunch of OS optimisation work on Lollipop and this is producing noticeable improvements on ARM equipped Android Kodi platforms.

[MrCrispy]

How is the performance, is there any difference in speed between OpenElec dual boot vs Kodi Android app? How is performance with large libraries + complex skins vs Chromebox?

I have a Chromebox now and looking for a 2nd Kodi box. Now that HD audio is supported finally, I'm considering Wetek Core.

[wrxtasy]

Just be aware HD Audio or Multichannel PCM Audio output is currently only available with Android.
It would help if you tell us what brand/Model you AVR is because there have been issues with certain ones I believe.

The tweaked versions of OpenELEC I distribute for the Core are quicker than Android Kodi, you would not be disappointed. There is not a lot in it these days and the speed gap has narrowed considerably between OE and Android.
I have not loaded it up with thousands upon thousands of video files but both are very usable and I've seen no complaints about lagging yet.

A SSD equipped Intel Box is always going to be quicker than any ARM device, that is just the way it is. The gap is narrowing yearly however.

[MrCrispy]

My AVR is Yamaha, RX-V475, I use HDMI out from it to tv.

[ChristianTroy]

Guys I have reverted that kernel commit from codesnake that I mentioned this afternoon, the one that handles the framerate automation when kodi sets 1080p24hz (and internally picks 1080p23hz), I flashed this kernel and tried WeTek Media Player removing write permissions to "/sys/class/tv/policy_fr_auto" to avoid it from disabling framerate automation and it worked without stutters, obviously it was using 1080p24hz instead of 1080p23hz so I re-introduced the old patch I was using...
Tried this new modified WeTek Media Player and, damn, it "kinda" works, I mean it still stutters but less. Also I have a TrueHD channel test that is 29.9fps that used to stutter and now it does not, so it looks like that just 1080p23hz is stuttering, but imho it's stuttering less than before.

I wanna try with fritsch build now

[fritsch]

Use latest and greatest androidtestv3 are builds done for the wetek core ...

[ChristianTroy]

After removing that patch I can surely say that 1080p23hz is the guilty.

I have tried your latest build, with refresh rate enabled playing a 23.976 movie triggers 1080p24hz video mode (that is the one with a stutter every 41 seconds), and it plays perfectly fine, stutter free.
Tried to "echo 1080p23hz > /sys/class/display/mode" and "chmod 644 /sys/class/display/mode" and the same file had stutters.

[fritsch]

Good - then please try to fiddle with the audio values - remember the commit I linked from memphiz? Do it like an engineer :-) interval halving.

If 8 is too large try 4, if 4 stutters, try 6 if 6 is okay, retry with 5 :-)

[ChristianTroy]

I tried another fr_auto mode that is enumerated in the kernel

Code:

const static char *fr_auto_mode[] = {
    "480p59hz",
    "720p59hz",
    "1080i59hz",
    "1080p59hz",
    "1080p23hz",
    "4k2k29hz",
    "4k2k23hz",
};

1080p59hz with a 29.9fps movie gives the same stuttering, so I assume that every video mode of these will just stutter.

@fritsch the kernel already contains those things as Memphiz took it from S8 according to the commit message

[fritsch]

https://github.com/christiantroy/android...hw.c#L2727 <- check

and try to multiply with 4 in the default case - as said engineering, changing stuff until one sees a pattern

Code:

default:
audio_N_para *= 4;
break;

And see what happens.

Here, see: https://github.com/christiantroy/android...hw.c#L2594 it always queries the 48k clock if I see this correctly, try to tune for 192 khz ...

Print out what this does: https://github.com/christiantroy/android...hw.c#L2457 and the one above, too - I think it's just setting for the wrong samplerate. We need 192 khz

[ChristianTroy]

Will try tomorrow morning and see what happens

[codesnake]

I'd try to comment out the lines that try to set special values for 1080p23hz and 1080p24hz display modes:

Code:

diff --git a/arch/arm/mach-meson8/hdmi_tx_hw/hdmi_tx_hw.c b/arch/arm/mach-meson8/hdmi_tx_hw/hdmi_tx_hw.c
index 15ec325..3c97ae0 100755
--- a/arch/arm/mach-meson8/hdmi_tx_hw/hdmi_tx_hw.c
+++ b/arch/arm/mach-meson8/hdmi_tx_hw/hdmi_tx_hw.c
@@ -2608,6 +2608,7 @@ static unsigned int hdmitx_get_aud_n(HDMI_Video_Codes_t vic)
static unsigned int audio_N_1080p24=0;
static void hdmitx_set_aud_n(void)
{
+/*
#ifdef CONFIG_AML_VOUT_FRAMERATE_AUTOMATION
     unsigned int audio_N_para = 6272 ;
     unsigned int audio_N_tolerance = 3;
@@ -2625,6 +2626,7 @@ static void hdmitx_set_aud_n(void)
         hdmi_wr_reg(TX_SYS1_ACR_N_2, (audio_N_tolerance<<4)|((audio_N_para>>16)&0xf)); // N[19:16]
     }
#endif
+*/
}

static int hdmitx_set_audmode(struct hdmi_tx_dev_s* hdmitx_device, Hdmi_tx_audio_para_t* audio_param)
@@ -2715,10 +2717,10 @@ static int hdmitx_set_audmode(struct hdmi_tx_dev_s* hdmitx_device, Hdmi_tx_audio
        }
     }
     if (audio_param->sample_rate == FS_48K) {
-#ifdef CONFIG_AML_VOUT_FRAMERATE_AUTOMATION
-        if (strncmp(vinfo->name, "1080p23hz", strlen("1080p23hz")) == 0)
-            audio_N_para=hdmitx_get_aud_n(hdmitx_device->cur_VIC);
-#endif
+//#ifdef CONFIG_AML_VOUT_FRAMERATE_AUTOMATION
+//        if (strncmp(vinfo->name, "1080p23hz", strlen("1080p23hz")) == 0)
+//            audio_N_para=hdmitx_get_aud_n(hdmitx_device->cur_VIC);
+//#endif
     }
     hdmi_print(INF, AUD "set audio N para\n");

@@ -2759,10 +2761,10 @@ static int hdmitx_set_audmode(struct hdmi_tx_dev_s* hdmitx_device, Hdmi_tx_audio
         default:
             break;
     }
-    if (strncmp(vinfo->name, "1080p24hz", strlen("1080p24hz")) == 0)
-    {
-        audio_N_1080p24=audio_N_para;//for recovery audio_N from 1080p23hz
-    }
+//    if (strncmp(vinfo->name, "1080p24hz", strlen("1080p24hz")) == 0)
+//    {
+//        audio_N_1080p24=audio_N_para;//for recovery audio_N from 1080p23hz
+//    }
     hdmi_wr_reg(TX_SYS1_ACR_N_0, (audio_N_para&0xff)); // N[7:0]
     hdmi_wr_reg(TX_SYS1_ACR_N_1, (audio_N_para>>8)&0xff); // N[15:8]
     hdmi_wr_reg(TX_SYS1_ACR_N_2, (audio_N_tolerance<<4)|((audio_N_para>>16)&0xf)); // N[19:16]

Sorry cannot test this now.

[ChristianTroy]

@codesnake
I had noticed that, and for that reason I tried what happened with 1080p59hz (and stutters as well) so I think it won't do anything.

BTW one thing is pretty interesting, example with 1080p59hz that stutters, changing this line with the value of the regular VMODE_1080P does make it stutter

edit: this is also interesting...

kmsg with 1080p vmode -> http://xbmclogs.com/pjyypjtal
kmsg with 1080p59hz vmode -> http://xbmclogs.com/pxg3vjgou

There is a difference here:

1080p

Code:

<4>[  137.213750@3] get cts = 148500   get n = 24576
<4>[  137.213753@3] hdmitx: audio: type: 12  CTS Mode: 1  VIC: 31  CTS: 148500

vs 1080p59hz

Code:

<4>[  524.897943@0] get cts = 140625   get n = 23296
<4>[  524.897947@0] hdmitx: audio: type: 12  CTS Mode: 1  VIC: 16  CTS: 140625

For the rest the logs are pretty similar

edit2: hardcoding the same values (cts and n) lead to no audio

edit3: when using MediaCodec Kodi uses the normal resolution (like 1080p24hz) and the internal mechanism is not turning it into 1080p23hz, that's why it does not make audio stutter.
What I have found is that it stutters when one of the "fr_auto" resolutions is used, no matter what playback method you use.

edit4: on s905 policy_fr_auto was disabled, I echo'd 1 there and forced 1080p24hz (it does not let me echo 1080p23hz says it's not a valid resolution) and it looks like framerate automation kicks in http://pastebin.com/czrvfcpj and I have no stutter

[ChristianTroy]

BTW today I also tried to set t he correct N/CTS pairs as per HDMI specs from here: http://www.microprocessor.org/HDMISpecification13a.pdf
It just stutters every 15.5 seconds, you can count it.

[BORIStheBLADE]

Anyone find out when they will be back in stock on their main site? They have been out of stock for weeks.