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

EQ プレーヤー available on Google Play, a finished, close sourced, Rockbox alternative for Android.

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)

[ploco]

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 §§§§§".

Sorry, my bad, can be found as "EQ Media Player"

[[Saint]]

...The freedom of parametric eq one may said.

FFmpeg Filters Documentation :: 6.35 equalizer

The more I look into it, the more I'm convincing myself that android-ffmpeg is the obvious choice.

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/

Oh, certainly. I understand that completely, and there's certainly no reason for this project to stop existing, especially not just because some guy (me) said some words on the Internet.

I suppose this was largely more of a philosophical discussion about starting anew, the future, and what exactly Rockbox consists of. If we can gain enough momentum to move in a particular direction, what do we bring with us, and what do we leave behind? What if anything defines Rockbox? etc.

I guess you are aware of http://gerrit.rockbox.org/r/#/c/683/

Yes. I was aware of this, thanks. But as with the answer I gave to ploco above, the more I look into it the harder it is for me to convince myself that android-ffmpeg isn't the obvious choice. Unless there is something I am missing from either a technical standpoint or something we need (see "what defines us?" from above) that it is totally lacking.


[Saint]

[wodz]

Considering current HW, ffmpeg is probably the best choice. Decoding is easy part. Decent UI and proper balance between features and usability is the hardest thing. Rockbox was designed with very constrained embedded hardware in a mind. Current mobile hardware is much more like PC and hence rockbox with its all architectural peculiarities is not the best fit. Symbian passed away for the very same reason. This is called progress :-)

[wodz]

For brave souls who can't live without rockbox on Lollipop here is *HUGE* hack which makes it running on ART. http://gerrit.rockbox.org/1211

kugel proposed other, cleaner solution but I don't know if I'll go around to work on this some more.

[p.h.]

For brave souls who can't live without rockbox on Lollipop here is *HUGE* hack which makes it running on ART. http://gerrit.rockbox.org/1211

What does patch set 2 change? I've applied set 1 and in general it works, but themes don't work and sometimes it spontaneously starts to act as if an user was pressing up/down/enter.

Does the kugel's solution preserve theme engine work?

As to the question what Rockbox is. Rockbox has many unique features still not implemented in any of existing Android music players. They make Rockbox so unique. Together with the way user experience Rockbox they compose what Rockbox is. At least from an user's point of view.

Only relatively recently rockbox DSP features were outperformed (but still not in every aspect!) by Viper's Audio DSP for Android (root required). See http://vipersaudio.com/blog/
Still, show me a mobile player with cue sheet support, extensive codec support (including AC3, WavePack and Monkey's Audio), gapless playback, resume and bookmark features (just to mention only a few first coming to my mind)...

And speaking of bookmarks and resume - I know a person, who reverted from Lollipop to KitKat just to have Rockbox working. That means something.

[wodz]

Patch set 2 should be functional equal 1 it is just a bit more correct and a little faster in some situations. Theme engine should be unaffected by this changes at all. I tested it in android simulator and default cabbie seems to be rendered correctly. I don't have android phone with ART runtime to check. In the patch we abuse button queue so in theory some interference is possible but honestly I can't see how in practice.

[wodz]

Found another bug in rockbox on android 5.0 which can lead to the crash. I have no good idea how to fix this one. The problem is that scroll thread issues lcd_update_rect() which in turn performs JNI calls. This fails on ART since scroll thread is not main. Maybe kugel will come out with some clever idea.

[yithar7153]

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.

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.

Looking at it from a practical standpoint, I think it probably would be best to use android-ffmpeg. I don't know the details behind how rockbox works exactly, but I do understand it was built for a totally different platform than Android.

In my opinion, no. It wouldn't be Rockbox. It would be a "not Rockbox" using android-ffmpeg with a native Android GUI wrapping around it. I'm pretty sure the heart of Rockbox is to bring life to old music players and add customization and playback options that wouldn't normally be possible with the original firmware. But that doesn't apply to Android. I don't think there's anything wrong with creating this sort of application, but I just don't believe it's actually Rockbox.

[ZincAlloy]

Right. Certain features that Rockbox has would be nice to have in an Android player; like file tree browsing, gapless playback, replay gain. Customization would be nice, but as long as I can find my music and it can be played back correctly, I could get used to it.

[BenBrown]

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.

I feel that if ffmpeg-android were used and a native UI built around it, with the purpose of enhancing the rockbox experience on android.  And it remained open source and retained the license and logo, then in my option it would be rockbox.  Not only in the spirit of the rockbox project, but the purpose of rockbox on baremetel players.  Rockbox was created because stock DAP firmwares suck, and people like to hack.  Native music player apps for android suck, they really suck, they suck really hard.  I would consider it an evolution of rockbox, not a reinvention.  Regardless the goal remains the same, enhance/augment the stock software.

I think you should split the topic tread here.