Rockbox mail archiveSubject: Re: HWCODEC
From: Jens Arnold <jens_at_jens-arnold.net>
Date: Sat, 24 Dec 2011 13:01:26 +0100
On 15 Dec 2011 Mike Giacomelli wrote:
> Over the last couple months there has been some discussion about what
> to do with HWCODEC following dreamlayer's forum thread. During this
After reading the replies to this so far and thinking about HWCODEC,
here are my thoughts.
> discussion, several developers still using HWCODEC mentioned that they
> preferred/recommended older builds over newer releases. The general
> opinion seemed to be that somewhere around 2.x-3.0 HWCODEC peaked.
I'm rarely reading the forum, so it is new to me that people actually
recommend old releases. I'd rather recommend to always use the latest
release or even latest svn. While some things became a bit worse (e.g.
binsize), there are also countless bugfixes and improvements which make
the latest version the best choice. One example is TALK_PARTIAL_LOAD for
the Ondios - committed last month.
> Over the years we've discussed the possibility of forking off HWCODEC
> and decided that there are serious advantages and drawbacks to doing
I'd rather not fork, at least not at this point or in the next few months.
> ***Greatly simplify large parts of the code for SWCODEC targets (see
> JdGordon's forum posts in rockbox general)
I fail to see how forking HWCODEC will actually simplify SWCODEC code.
All it does is that it removes a number of #ifdefs (of which aren't all
that many outside the actual playback system).
I'm also an advocate of keeping stuff similar wherever possible. This
will actually simplify code, and also give it more testing (because it's
running on more targets) so bugs are (hopefully) found earlier.
Here are a few examples:
1) The playback engine. Atm the playback engines are completely
separate, but it doesn't need to stay that way. The swcodec engine is
more capable than the hwcodec one (due to its architecture), and can
(and should) be ported to hwcodec as well. Of course it needs some
adaptations, mainly the codec handling part, but then it will offer
actually new features on hwcodec (e.g. integrated wav/aiff playback). A
notable exception here is the Player, due to its older MAS.
2) The button bar, lcd icons (on the Player), and some other means of
signalling status (e.g. the multicolour LEDs on the X5) could be unified
into a general status system. That way theming wouldn't need to deal
explicitly with either. The button bar could be implemented in a theme
using the status variables of that system.
3) Charcell itself. While it isn't possible to completely unify charcell
and bitmap, some differences are artificial, e.g. the unavailability of
viewports. Viewports would be *especially* useful on a screen with as
few characters as the one of the Player.
> ***Enable us to arrest and hopefully reverse the slow bin size
> increases that are squeezing HWCODEC to death by simplifying bits of
> rockbox that are simply too awkward to do with ifdefs.
See above. I also want to mention that there is a way around the hard
limits (200 KB for .mod/.ajz on Player and Recorder V1, 400 KB for .ajz
on FM/V2 and the Ondios, ~228 KB for Rombox) by using a bootloader like
we do on the swcodec targets. The .ajz/.mod would only contain the
bootloader, the main rockbox binary would be /.rockbox/rockbox.archos
like on the other targets. This will also reduce main binary size a bit
because all the coldstart code can be removed from it (including the
charging screen, which would be part of the bootloader). The bootloader
could also reside in flash. This is actually one of the first things I
want to work on.
> ***Prevent developers unfamiliar with HWCODEC from breaking it.
That can be solved by a call for testers. Of course one cannot expect an
immediate reaction (like a certain dev sometimes seems to). This is not
hwcodec specific though, it applies to all less common targets (MIPS is
a prominent example - I guess it's easier to find a HWCODEC tester than
to find an Onda tester).
> ***Only a few people are working on HWCODEC, so if we did fork it,
> would it just continue to rot?
> ***Duplication of effort for fixes in common code
That is my main concern: forking means more additional work for porting
bug fixes and useful features (yes it's not just fixes!) than what will
be saved for SWCODEC by forking. Likewise, if something new/ interesting
pops up for hwcodec, it means extra work to port it to swcodec. It will
become harder over time when code bases are diverting.
> ***HWCODEC is useful because it reminds us to avoid needlessly
> bloating file size (although this is probably no longer true since we
> have SWCODEC targets with more memory constraints)
It's not only binsize but also the fact that hwcodec uses another CPU
architecture. Having Rockbox running on several architectures is useful,
e.g. does it allow for easier debugging in some cases (anyone knows the
memory guard feature? - it's available on coldfire too though).
The MIPS targets have less active developers around afaik, but nobody
suggests to fork or remove those. I'm not, either.
> Over the years I think the advantages have become more appealing
> because its becoming harder and harder to keep binsize small enough to
> fit into some HWCODEC targets. While at the same time, we've got low
> memory SWCODEC targets that are arguably more constrained by total RAM
The problem that some bugs are hiding for months is not mainly due to
too few developers running the latest version (HWCODEC or not), but due
to developers not using all features. This will only get better with
code unification (as I explained above) - forking will make it worse.
It's also a tradition that we never removed a target from rockbox which
has at least one active maintainer (or is similar enough to another
target having one) and is in usable state. The only target we ever
removed (actually a whole architecture) where the Gminis (calmrisc16 +
calmmac24) when its only developer left rockbox (and said so). The
chance of anyone picking up this port again was essentially zero (16 bit
architecture with specially patched gcc, also harvard architecture with
no code ram at all (all code had to be flashed!)).
Of course, forking is not removing, but it's raising the bar for
developers of those targets.
So to sum it up, I'd not fork hwcodec now or in the next few months. Of
course the situation should be re-evaluated regularly.
-- Mit freundlichen Grüßen / Best Regards Jens ArnoldReceived on 2011-12-24