Xduoo x3

[speachy]

Newer compiler exposes bug in mips threading code. Thats why vortex's sources compiled with 4.9 crash. I fixed this bug in rockbox but I am almost sure something during agptek merge broke it again.

http://gerrit.rockbox.org/r/#/c/1905/

Lifted from the Fiio X1 WIP code.  It boots, but success was short-lived.  When attempting to play:

*PANIC*
Stkov codec

Work-in-progress, eh? 

[wodz]

http://gerrit.rockbox.org/r/#/c/1905/

Lifted from the Fiio X1 WIP code.  It boots, but success was short-lived.  When attempting to play:

*PANIC*
Stkov codec

Work-in-progress, eh? 

codec stack overflow - pretty easy to fix. Just increase codec stack size definition and check if that helps.

[speachy]

codec stack overflow - pretty easy to fix. Just increase codec stack size definition and check if that helps.

I bumped it from its default 9KB (ie 1KB "default" + 8KB codec) to a combined total of 24KB, and it's now playing music.  Working my way back down to find the threshold.  (EDIT:  10KB is too small, 11KB is okay)

Unfortunately, it's not able to sustain realtime playback, pausing for about 1 second roughly every 5 seconds on a 320KB mp3.  The entire player goes unresponsive during these pauses.

I'll keep poking at it next time I take a break from household cleaning.

EDIT:  Dropping the updated mips thread code onto the original vortex tree allows it to work, with realtime playback and a responsive UI.
EDIT2:  Just after I wrote said that, the player hung in the fft plugin, requiring a hard reset.

[speachy]

Unfortunately, it's not able to sustain realtime playback, pausing for about 1 second roughly every 5 seconds on a 320KB mp3.  The entire player goes unresponsive during these pauses.

From what I can tell, the inability to do realtime playback is due due to _very_ poor SD read speeds..

(Looking at the buffering thread debug output, it seems to take about ~1s to fill ~180KB of buffer data, even when starting a new track..)

[saratoga]

Could try some video game music.  NES or SNES files are a few kilobytes

[speachy]

Could try some video game music.  NES or SNES files are a few kilobytes

I tossed a couple of 25-year-old protracker .MODs on the X3, and it's puttering along with no effort whatsoever.  Granted, that's a lot less CPU-intensive than decoding mp3s, but it supports the theory that the SD driver is the culprit.

The X3's jz4760's SD code was something I substantially altered from the vortex sources when forward-porting to rockbox mainline -- necessary due to the SD/storage thread rework that landed a while back -- but the result was nearly identical to the jz4740 SD driver, with the differences due to the '60 having two SD controllers & slots.  Consequently, I suspect that the Onda VX7x7 and other '40 targets also share this SD problem.

[speachy]

Still poking.  Found out we're driving the SD peripheral off the wrong clock source and likely using the MAX divider too.  Fixing that seemed to improve things marginally.  Heavily updated the debug menu.  Accumulating a small pile of minor fixes things here and there that should be safe to apply..

Another data point is that the player can barely manage slightly better than realtime playback if we're on the final track of a folder (with repeat off).

It could still be the threading code isn't sane; taking to long to context switch or schedule, or perhaps not managing cache invalidation sanely.

(It would be really nice if we had someone with one of the jz7440 targets that could provide additional data points...)

[speachy]

Okay, found the culprit.  Part of the AGPTek Rocker merge was a change that disabled compiler optimizations for libmad, thus trashing mp3 decoding performance (and smashing its stack!)
 flac, wmv, m4a worked fine.  (vorbis is being stupid, but I'll get to that later..)

I have a series of patches in gerrit now, awaiting review and merging.   Two are essential,:

  http://gerrit.rockbox.org/r/1905
  http://gerrit.rockbox.org/r/1907   (EDIT:  #1907 has been committed)

but I think all of the patches in that series are worth applying.  I think that this fix from the X1 series is also advised:

  http://gerrit.rockbox.org/r/#/c/1797/

Gerrit won't let me add any reviewers, and I have no commit rights, so this is all I can do.

[wodz]

Threading error fixed in #1905 was spotted by me but who cares :-) Anyway I lost ability to merge patches from gerrit :-/

[Dulus_No]

xDuoo X3-II got a Rockbox port: https://vk.com/wall-85070453_8323

[wodz]

Pretty frustrating they didn't bother to contact rockbox team in any way.

[wodz]

If anybody knows the relation between the "rockbox.bin" bootloader file in the xvtx.ru installer and what actually ends up on the NAND that would be interesting. (I think "nprog" must be doing some equivalent of relocating segments of the .bin file into different parts of the first NAND partition.)

Here is reply from xvotex regarding bootloader update image:

Hi.

You're right, X3 boot combined from header, SPL1, rockbox bootloader and uBoot.
This was done manually in a binary editor and a very long time ago.
Unfortunately, I did not have any information on this except what already in repo. sorry.

Regards,
Roman.

[speachy]

(vorbis is being stupid, but I'll get to that later..)

The failure is in the ogg frame checksum code -- and the underlying cause is due to the mips asm memset() routine being defective.

Threading error fixed in #1905 was spotted by me but who cares :-) Anyway I lost ability to merge patches from gerrit :-/

I'm not trying to claim credit for code that's not mine.. but someone has to do the work to get things merged...

[wodz]

The failure is in the ogg frame checksum code -- and the underlying cause is due to the mips asm memset() routine being defective.

That is strong statement. AFAIK this implementation is copied from some respected source. It has some quirks (like byte copy for small sizes).

[speachy]

That is strong statement. AFAIK this implementation is copied from some respected source. It has some quirks (like byte copy for small sizes).

Be that as it may, the empirical evidence points to memset() not working properly.  Disabling the asm memset() allows the vorbis code to work.

(It's setting a 4 byte unaligned buffer to 0 before running a checksum algorithm)