From: Thomas Martitz <kugel_at_rockbox.org>
Date: Sat, 24 Dec 2011 14:07:23 +0100

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 (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.
>

You advocate, fine. But you don't _do_. Seldomly, at least. I
acknowledge the recent talk.c refactoring is positive exception.


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

You have been telling this for years. But nothing has happened. In the
meantime the #ifdef-hell and other things have been a PITA for "normal"
(i.e. those without hwcodec) developers.

I can tell from my buflib project. It would have been a lot easier of
the playback engine had at least similar api. As this wasn't the case I
needed unify it partly which was quite some effort do do correctly (see
the number of talk/voice related bugs I introduced). And to be honest,
I'm not even sure if it's correct now.

You list a number of solutions, which solve or at least lessen the
hwcodec problems. But I heard this solutions so many times by now. In
reality they don't happen. HWCODEC people really should do something if
they want Rockbox to develop further on these devices.

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

This really can be done only by hwcodec specialists. Those aren't active
these days. This is the exact reason why the recorder8mb was taken off
the build table instead of implementing the above solution (which has
been proposed by some people).

> 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).

This has been done. But the calls are often unheard. You're right about
the MIPS targets. They *much* less of a maintainance burden, though. In
99.9% of the time you can implement things without extra maintainance
work on MIPS and it'll still work.


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

Currently it's the other way around. More additional work is needed to
keep hwcodec functioning, let alone implementing new features for it.
But worse, that additional work is largely done blindly by people which
don't even hwcodec targets. Even more worse. the work //is the result of
the pressure to keep the build table green. So stuff tends to be poorly
implemented.

The work for hwcodec should be done by hwcodec people. But these people
are not active anymore or are using old builds. Both sorts are not
beneficial for the current code.


>
> Further comments:
>
> 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 both. It's a problem of too few *active* developers testing/running
stuff on HWCDEOC. And it's a problem because Rockbox has so many
features, they just can't be covered by the very few HWCODEC devs.

Also code unification is nice, but it doesn't solve all problems and it
doesn't make testing unecessary. Many things can't be reasonably
implemented in a unified manner. And even then, things cannot be tested
properly.

Testing is a problem. The people that have hwcodec are largely inactive,
and unreachable in a timely manner. It's perfectly fine to go inactive,
but it's unfair to expect other people to keep things working in the
meantime.


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


I say, instead of the few hwcodec devs telling about possible solution,
they should step up and do something themselv, because it's too much of
a burden for devs that have nothing to do with hwcodec (or charcell)
otherwise.
If that doesn't happen the only useful way I see is to fork hwcodec. To
simplify life for the devs who are actually actively contributing currently.


I see my mail is a bit of a rant. But Jens' mail just repeated stuff
that has been said numerous times, including at the last DevCon. The
facts are: Very few active devs are doing hwcodec, nobody does the
needed work, testing is mostly not happening and the code is getting
more and more a nightmare

Best regards.
Received on 2011-12-24