iBasso DX50

[cholero]

Hello. My status in this project is that i'm quite far but I still would like to optimize some things first before doing a commit.

But why i'm writing is that i need some help from a developer. Ilias port has always had the problem that as soon as playback starts, all timer acitities are slowed down by a factor around 2.3 (backlight timeout, scrolling acceleration, stopwatch, etc.) . When playback stops or is on pause, everything is normal again. can it be that a timer tick takes too long time and lets some other timer slow down? To be more specific: that the pcm_tick takes too long? I dont know much about timers and maybe I could find it out myself, but a small tip from a experienced dev. could save me hours of investigation .

Edit: no more help needed, foud how to solve the problem partly.

[wodz]

As was pointed out earlier you should really, really put your work-in-progress on gerrit. That way others can review the code on early stage saving you hassle later.

[cholero]

Uploaded the code to gerrit:
http://gerrit.rockbox.org/r/#/c/941/

[__builtin]

The link to the bitbucket repo seems to be down.

[__builtin]

Never mind, it's just the period at the end of the URL... 

[cholero]

Good news: headwhacker announced to have solved the "gather runtime data" - bug for this port. 

[saratoga]

I committed the port.  However, its not integrated into our build system.  From what I understand, we don't current build Android targets over the build system.  Is there a technical reason why we could not build the DX50/90 devices this way?

Also, I've created a wiki page:

http://www.rockbox.org/wiki/IBassoDXPort

Filling this out with install directions and any other useful info would be great.

[cholero]

Thanks a lot for everything!
I don't know why android apps are not build, didn't do the reading for it. But it is not impossible that the reason could also affect DX50/90 port.?
At current state, no simple installation is possible. But I will try to get further with this. Also writing the wiki and fixing the DX90 port (maybe headwhacker helps me, now that it is so easy to get the sources) are my homework. I only have limited time (some hours a week) but I will bring this port to the end if my abilities allow it

[cholero]

I had a spontaneous idea for the update mechanism:
The app and libs could be installed to the data partition. The dualboot-app (/rbutil/ibassoboot) could be extended to manage updates, so if there is a rockbox.zip on the sdcard it updates the rockbox app on the data partition. So the official firmware would only need to be patched once with the dualboot-app.

[[Saint]]

I committed the port.  However, its not integrated into our build system.  From what I understand, we don't current build Android targets over the build system.

So, I screwed up.

If anyone read the comment I posted prior where I confirmed and agreed with this, I apologise.

It seems Android targets are indeed hitting the build table, and that Chrome decided to hate me and not show them (and may other) items in the build table. Serves me right for religiously using Chrome-dev I guess.


[Saint]

[cholero]

a very small breakthrough for the installation process: Because my mate headwhacker form head-fi insisited in trying to install the whole rockbox to /sdcard (internal drive) we tried to find a way and found it. With this way it will be possible to do updates of rockbox using only mass storage, nothing else  . I will do some more testing and post a patch when I'm 100% sure it works.

[saratoga]

The DX50 is now actually built by our build system:

http://build.rockbox.org/dev.cgi

The first build went smoothly:

http://build.rockbox.org/shownewlog.cgi?rev=be9c227;type=ibassodx50

[cholero]

Wow, that's great!
We are getting further and further. Thanks!

I have a question about folder structure. Until now we had the content of the rockbox.zip on the system partition. Also the libs/armeabi/* was on the system partition in an other folder. The user setting were on /sdcard/rockbox. Now if we move the binaries to sdcard, how sould it be done?

a)
everything (settings AND build) to
/sdcard/rockbox
libs/armeabi to
/sdcard/rockbox/bin

b)
build to
/sdcard/.rockbox
settings remain in
/sdcard/rockbox
libs/armeabi to
/sdcard/.rockbox/libs/armeabi

or even something else?

On my known players (H120 and clip+) it is the way a) but with a dot (.rockbox)


Edit: I think I have a basic lack of knowledge about the android port. Right now we are running the rockbox binary in the folder with all the lib*.so 's from libs/armeabi. But is this necesary? All files are already in the zip. Is it possible to run it without the lib*.so's?

Edit2: My gerrit patch uses finally this folder structure:
everything (settings AND build) to
/sdcard/.rockbox
libs/armeabi to
/sdcard/.rockbox/codecs

[cholero]

Next step:
DX50 (& hopefully DX90) run well from sdcard:
http://gerrit.rockbox.org/r/#/c/993/

This will simplify the update procedure of rockbox by a big amount.

to try the installation (tested on DX50) when coming from ilia's build:

• build the dualboot selector in rbutils/ibassoboot with ndk-build and copy the build (MangoPlayer) to /system/bin/
• copy rbutils/ibassoboot/chooser.bmp and rbmissing.bmp to /system/
• build rockbox: make zip
• copy the content of the rockbox.zip to the internal drive /mnt/sdcard

The new file structure differs only by the codecs filenames from a regular build  .

Edit: Had to change the gerrit address because I made accidentally a new commit instead of a new patch set

Edit2: with modified buildzip.pl even 1 step less is needed :-)

[ArgelErx]

I'm currently tinkering around with this build. It builds and it works. Moving the rockbox directory to the sdcard is great.

The only thing i do not like is the current keymap. Specifically hold switch and power button interaction with the touchscreen/backlight.

As it is right now
- every press of a physical button turns on the touchscreen.
- the hold switch locks the touchscreen and the physical buttons.
Which is really annoying if you try to use the device blindly (e.g. while it is in your pocket).

In my personal build i reverted the behaviour somewhat back to the original implementation by isergachev:
- Hold switch only toggles  touchscreen lock/backlight.
- Hold switch only locks power button short press (to prevent accidentally leaving WPS).

I tried doing this with the rockbox infrastructure, but failed miserably (to much unfamiliar code and concepts in to short a time). So i hacked up the iBasso key code.

IMHO the power button/lock switch behaviour should be this (for this device):
- Hold switch only toggles touchscreen lock/backlight.
- Power button short press only toggles backlight.
- While hold switch is set to lock, no button press or automatic interaction (e.g. caption backlight) turns on the touchscreen/backlight.
- Current function of the power button (back/abort) can be fully replaced with touchscreen interaction.

Any comments?
Can this be achieved "The Rockbox Way"?
Can this be made the default behaviour? Or at least be customizable?
Or will i ever need a custom build for this?