|
Rockbox mail archiveSubject: Re: HWCODECRe: HWCODEC
From: Mike Giacomelli <giac2000_at_hotmail.com>
Date: Sat, 24 Dec 2011 14:40:54 -0500 >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 HWCODEC. >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). Mike Received on 2011-12-24 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |