Rockbox Development > New Ports
Rockbox as an Application (Android, WebOS etc.)
wodz:
CheckJNI doesn't help much. It seems that what causes problem for us is stack overflow check introduced in ART. This is because of complex threading model of rockbox on android. Soft threading on native side is rearly used so this kind of problem is not common.
[Saint]:
It is probably an unpopular opinion, well...maybe yes, maybe no, but here goes:
Going forward with Rockbox as an app on Android, if we want the project to have a future, I think we need to abandon the current model entirely.
Now, I understand that might ruffle a few feathers, but I think that everyone with an understanding of the mechanics behind the scenes in this port would find it incredibly difficult to argue against this position. I myself didn't particularly want to acknowledge this position for a very lengthy period, and I sincerely believed that we could make it work and that the project had a future in its current form.
I have several git repositories full to the brim of attempts to make the user interface for Rockbox on Android devices functional and intuitive. These efforts of mine spawned the inception of no less than a dozen new theme engine tags and syntactical changes that really pushed the limits of what is possible to achieve with our (absolutely awesome) theme engine.
But slowly (mostly because I was in denial and I didn't want to accept the fact that I had spent literally hundreds of man hours on what I now feel is an absolute dead end) I came to realise that no matter how much I pushed the limits of our theme engine that I wasn't ever going to come close to what I can achieve with a native user interface.
There is a saying of being or not being "in the same ballpark", but in this case not only was I not in the same ballpark, I wasn't in the same city, state, country, continent, or even the same planet. To top it all off, instead of bringing a baseball bat to the ballpark...I brought my ice skates.
It is my honest opinion that if Rockbox is going to have any form of a future on Android that there is only one path that leads to that end. What I sincerely believe needs to happen is the completion of a completely standalone Rockbox playback library wrapped in a native user interface.
This put me in somewhat of a difficult situation.
Although I am perfectly capable of creating a beautiful native UI for any given Android application (I actually think myself to be fairly talented in this regard. If I might blow my own horn, so to speak), I do not have the skills required to create or complete the standalone playback library that would be the core of such a project, and until a standalone library for Rockbox exists and I can examine the API(s) and function calls, I can't put any meaningful work into creating a native user interface.
If at some point Mr. Someone does manage to push out a standalone library that I can work with, I will write the shit out of a user interface that can effectively target everything from ancient old Android 2.1 (Eclair) right up to whatever the current iteration of Android is at that time (6.0 Marshmallow at the time of this writing). Android provides extensive compatibility libraries, in particular, android-libcompat, which would allow me to bring Android's Material Design aspects into the user interface for Android versions right down to 2.1, even though at the time of this writing Android 2.1 and below occupy less than 0.1% of the market share of active Android devices.
Now, I don't want this post to turn into a novel, but the approach of using a standalone Rockbox playback library brings with it some other interesting philosophical considerations.
The most obvious one being "What actually makes 'A Rockbox'"?
If one strips the idea of using a standalone playback library right back and examines the guts of it, really the only interesting thing that I believe that we can bring to the party here is our extensive codec optimizations, but even the worst and oldest Android devices can be substantially more powerful than most digital audio players Rockbox targets, and modern mid tier and flasgship devices are extremely, extremely powerful when compared to digital audio players. Even on MSM72** ARMv6 SoC, which by today's standards even for cheap low end and midrange devices is woefully underpowered, we are getting ~3000% realtime decode for LAME 320 CBR, and ~7000% realtime decode for flac8 lossless.
This begs the question, "Why use Rockbox as a base at all?".
The most obvious candidate for a 'not Rockbox' core is android-ffmpeg, and this has the overwhelming benefit of already existing.
But...if I were to build a native user interface around android-ffmpeg, one of the numerous libraries for playlist handling, etc. etc. etc. ...is that still Rockbox? Is it Rockbox just because I say it is? Even if we're not using our codecs, or our playback control, or our playlist control, if we have no plugins (lets face it, plugins in Rockbox on Android make zero sense), no theme engine (bringing our own theme engine to the party in a modernised Rockbox for Android brings with it a host of difficulties), can I still in any good conscience call it Rockbox?
I would like to know how others feel about the points raised here. Please try to separate and personal feelings one might have about myself, or any sentimental feelings one might have for Rockbox from this discussion and examine only the practicality of the current situation and that of my suggestions, thank you.
[Saint]
EDIT: If this post gains some traction in the responses I will split this conversation out into a dedicated thread.
ploco:
[Saint]: leave aside the "bake me a cake, so I can decorate it." feeling and currently not able to playback on 5.0 ART.
I will provide you some facts here:
Not only androd-ffmpeg, libVLC also has a Android demo come with GUI.
So what could differ libRB from libVLC? The freedom of parametric eq one may said.
but there is an app call EQ プレーヤー available on Google Play come with parametric eq and a really nice graphical eq gui.
that's right, a finished, close sourced, Rockbox alternative for Android.
by the way,I tried to build libVLC's demo once, but that messy dependency remind me of maven projects - which I hated fully.
If you really want this libRB for real, why not start from create a list of all the functional requirements?
not just some "need a play function" but name of the function, parameter etc,
because the instruction sets(commands) might end up be a huge lookup table anyway.
another hackish way is modify the setting in config.cfg on the fly on Java side, then trigger apply (only to the changed set) in native side.
at lease that's how I tried it. but dropped the whole idea later.
wodz:
Well, fiddling with RaaAoA is just some fun excersize for me. Just like hacking rockbox in general. Some people like solving puzzles some like reverse engineering, disassembling and hacking. I guess you are aware of http://gerrit.rockbox.org/r/#/c/683/
steak:
[Saint]
Although I know very little about software & hardware engineering, I do understand what you say about Android OS and Android based hardware being far more advanced than rockbox. And I do have some understanding of what you saying about rewriting a rockbox for android from scratch.
That said, may I, as I did before give my end user point of view on rockbox.
I would not mind a new rockbox as long as it has similar interface, settings, ability to be configured through cfg files and so on.
Yes plugins don't make much sense.
Although I'm VERY happy with folder navigation (and edit, move, etc... on the fly) I'm still looking for the device that will allow me to use the database functions with 32~64Gb of music files. An android device should, mine doesn't, maybe it's not as recent & powerful as it should, maybe rockbox as an app is not optimized. This would be the only thing I need.
About the functions, settings, etc.. I use or not, there's no point in giving too much detail, let's just say I don't use all of it but everything I use is VERY useful to me AND I guess the rest is VERY useful to others. Not just each function & setting but also the interface that's similar accross all "ports" = Android or Not.
From my user perpective, it's a huge point having =
Lots of functions, settings, shortcuts,...
The same interface
Although I'm not blind, I guess it's a great point for blind users to be able to keep rockbox from one port to another. I don't know if "rockbox as an app" can be configured for a blind user like the conventionnal ports but surely this is one USEFUL thing.
I have tried a few android media players, they are powerful, they read multi codec, but they all have the same database interface that is a pain to use for me (takes ages to find a track if for instance I cannot remember its title, it has many versions on my device, etc...) Browsing through my folders organised as I like, I find things in (almost) a glimpse !
Shortcuts are great to access to my main (sub)folders, settings, cfg files, etc..
Creating/editing/managing multiple playlists that I can read/edit/manage further on my computer is THE MOST useful feature for me as it makes rockbox the perfect tool for sorting out my music collection as it (always) grows
Finally yes I am not an expert, but compared to many rockbox users I know (mostly those I introduced to it), I am an expert user. If rockbox is rewritten from scratch, I just wish I'll still be able to use its functions in a similar way (txt files, etc..) and without being a real geek
--- Quote from: ploco on September 15, 2015, 07:58:26 AM ---EQ プレーヤー available on Google Play, a finished, close sourced, Rockbox alternative for Android.
--- End quote ---
I clearly don't want to drop rockbox but I'm interested. Could you write the name of the app on Google Play in regular letters that I or anyone can read & use ? Here whatever you wrote looks similar to "EQ §§§§§".
[Saint]
Good thinking wanting to keep something that can be used from android 2.1 = A good player does not need to be the latest & most powerful android platform, it just need to offer good sound and be "stable". The global market ignores them but millions of people don't need to buy the latest gadget, especially when they cannot afford it or have other priorities. (like helping the planet a little)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version