>After reading the replies to this so far and thinking about HWCODEC,
>here are my thoughts.
Thanks for commenting, you're probably the developer whose opinion I
am most interested in.
>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:
This is in part why I thought if we forked we would leave SWCODEC in
the forked branch. My thinking was that further work on HWCODEC and
SWCODEC integration could continue with the goal of optimizing
>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.
Multiple architectures are useful, which is why I like having CF and
MIPS around, not just ARM :) They're implemented in such a way that I
don't have to have a MIPS or CF target to work on new features.
Actually, I've been working on rockbox for 5 years now and have been
quite ok working on lots of things for MIPS and CF without ever having
one of those devices (e.g. WMA, MDCT library, AAC optimization, etc.)
because these targets are implemented nearly identically to all other
SWCODEC targets. Its not that the Archos players are SH1, but rather
that they are HWCODEC. I would be happy to have SWCODEC SH targets,
and less thrilled about HWCODEC ARM devices.
>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).
I wasn't proposing removing HWCODEC from rockbox, I was proposing
creating two branches, one for SWCODEC devices and one for both types
of devices. Development would continue in both, both would be built
on every change, released every 4 months, etc. I don't even think we
should remove SWCODEC from the Archos oriented branch, because as you
pointed out there are advantages to having it around. There would
never be an end to HWCODEC.
What I was proposing is that we stop trying to compromise to meet the
needs of all targets in one branch, and instead have one branch where
SWCODEC evolves on its own, and another where SWCODEC and HWCODEC
evolve together to meet the needs of the archos players (and i suppose
any other very low memory device).
Received on 2011-12-24