On Sat, Apr 20, 2013 at 5:37 AM, Michael Sevakis jethea...@sbcglobal.netwrote:
BTW, ideally the rbcodec lib shouldn't rely on any code elsewhere in the
rb tree.
True, but one step at a time. :-)
Yeah, just wanted to point it out. Nice work on the sw vol, means rbcodec
is no longer looking
On Fri, Apr 19, 2013 at 2:39 AM, Michael Sevakis jethea...@sbcglobal.netwrote:
Changes over here:
http://gerrit.rockbox.org/r/#/**c/456/http://gerrit.rockbox.org/r/#/c/456/
BTW, ideally the rbcodec lib shouldn't rely on any code elsewhere in the rb
tree.
BTW, ideally the rbcodec lib shouldn't rely on any code elsewhere in the
rb tree.
True, but one step at a time. :-)
I think this patch would just leave header files. Nothing now in
librbcodec's own SOURCES file would bring in any code.
For warble, there are still four dependencies (after
Changes over here:
http://gerrit.rockbox.org/r/#/c/456/
Am 24.12.2011 20:40, schrieb Mike Giacomelli:
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
Hi all,
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
Am 24.12.2011 13:01, schrieb Jens Arnold:
Advantages:
***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
because Rockbox has so many features,
they just can't be covered by the very few HWCODEC devs.
which pretty much means something I'd like to see since quite a while:
automated (unit-)tests. And it's not a HWCODEC problem, the same
problem exists on SWCODEC. The only difference is that there are way
or no feedback.
which pretty much means something I'd like to see since quite a while:
automated (unit-)tests. And it's not a HWCODEC problem, the same
problem exists on SWCODEC. The only difference is that there are way
more users for SWCODEC targets, and (at least some of those users)
file bug
Le 11-12-24 07:01, Jens Arnold a écrit :
Hi all,
Hello,
Of course one cannot expect an
immediate reaction (like a certain dev sometimes seems to).
No secret please, name this certain dev or just don't mention him at all
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
HWCODEC
essentially unmaintained. People would basically be stuck with
whatever bugs were built into the release or build they decide to stay
with.
I agree with forking out HWCODEC into a legacy series. It has many
advantages, while the only real advantage that keeping it in has (which
forward because in
practice if people do not upgrade, then we have left HWCODEC
essentially unmaintained. People would basically be stuck with
whatever bugs were built into the release or build they decide to stay
with.
I agree with forking out HWCODEC into a legacy series. It has many
On 16/12/11 03:57 AM, Rafaël Carré wrote:
However I think we are a few wanting to know amiconn's opinion since
he's been quite involved in archos port and he has some expertise that
could be helpful.
I agree that expertise is needed.
Also, people with HWCODEC devices are needed. The sim can't
Le Wed, 14 Dec 2011 20:50:50 -0500,
Boris Gjenero boris.gjen...@gmail.com a écrit :
I don't mean to force the issue. I realize others have been far more
involved in Rockbox, and I'm okay with whatever is decided.
I think the choice is ours as a group, not something which should be
decided by
On 12/15/2011 02:50 AM, Boris Gjenero wrote:
If developers want to retain HWCODEC support in the trunk, I can't
complain about that. However, if the latest version is not the best
choice, users should be told that. Also, in that case, the older version
they're directed to should at least get bug
***Greatly simplify large parts of the code for SWCODEC targets (see
JdGordon's forum posts in rockbox general)
***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
Hi everyone.
Over the last couple months there has been some discussion about what
to do with HWCODEC following dreamlayer's forum thread. During this
discussion, several developers still using HWCODEC mentioned that they
preferred/recommended older builds over newer releases. The general
issue isnt so much HWCODEC but CHARCELL support (which just
happens to be HWCODEC). (also low ram targets).
As I said in the forum post, all the ui customisability could be
easily be removed in a low-mem config (which could even be done in svn
if that is wanted).
The topic really should
On 15 December 2011 12:50, Boris Gjenero boris.gjen...@gmail.com wrote:
Apparently, there are few HWCODEC users, and I'm not sure if any developers
regularly use current builds on HWCODEC targets. Because of that, there
isn't much focus on improving things for HWCODEC.
On this point, I
I think we should consider branching into rockbox and rockbox-classic
I think we can find a better name than classic to avoid confusion
with ipod classic.
--
Rafaël Carré
FS#10853 adds skin support to the FM screen. its tested and almost
ready for commit but has had absolutly no testing on HWCODEC targets.
there is some special handling in svn to be able to record from the FM
screen on those so without testing I have no idea if its broken or
not.
So test it out
22 matches
Mail list logo
