Devcon 2006 Notes

Headers are the agenda, bullets are the notes.

Archos

PCM codec, recording framewalker, perhaps playback framewalker, late bitswap

• Bitswap should be changed to not run until needed, much like sw codecs.
• Playback code should be merged/assimilated into the sw codec code, so we don't have two code bases to maintain.

How to handle new features, with the codesize already being critical

• Many new features are not avalable for Archos anyway (due to hardware limitations). But we need to make sure they don't inflate the shared code so it doesn't affect Archos negatively.

---

iPod

Discussion of how to implement support for accessories

• Generally agreed that the iPod accessory port has interesting capabilities.
• Lack of a "killer accessory" makes actual coding interest limited.
• Communication could be done with TSR plugins.
• Christi wants to use her Nano as remote for her iPod...

---

Sound Playback

A playback buffer renovation

• Buffer handling needs to be refactored, current code too complex to fix the bugs.
• Put metadata/album art/lyrics/other on the codec buffer with a simple linked list of pointers to metadata / track starts
• Split playback.c into manageable logical partitions
• Playback system unification between hwcodec and swcodec

Have an additional layer on hwcodec targets for pre and post bitswap

• Basically make bitswap a codec

Loadable mas codec for hwcodec

• For wav

A unified status to indicate playback and recording state

See AudioAPIEnhancement for more thoughts on this

---

Radio / Record

Discussion on how to extend the WPS system to radio and recording

• Dan's wps parser is a good idea, but nobody has looked at the code yet...

---

Project Administration

How to deal with the patches/feature requests/bug reports, can we do it better? should we close really old ones?

• Nagging: Biweekly mail to committers list with all open bugs and all patches, sorted oldest-first.
• Start looking into if moving to Subversion or Git can make patch handling easier.

How to improve the release process and be more rigorous about recording and fixing bugs and ensuring full functionality on as many platforms as possible

• Christi donned the "release manager" hat and guided the team into creating a ReleaseTodo for 3.0 and 3.1.
• The new general ambition regarding releases is now once every 6 months.
• Bugfix releases (i.e. 3.0.1) between major releases are a possiblity but should be managed outside the core dev team. Applying bug fixes isn't difficult and can be done without being a programming expert.

---

Build / config / source tree

How to improve portability, get a more generic code base

• Linus described the new TargetTree concept, basically splitting up drivers into target-specific files, thereby solving much of the #ifdef mess from driver code.

How to make a more generic button/key approach so that the hurdle for new ports don't continuously add up in regard to the key assignments in plugins

• We need to analyse the code and make a big list of all actions that are available in the core system (not plugins). Then we put that list into one file (per target), hence being able to reuse mappings in file browser and menus for example.
• This removes a lot of #ifdef mess from the application code.
• Plugins can also use this list, thus avoiding having to create and maintain their own button mappings for every target. They can also still override it with their own way of doing things.
• The button driver should send better preprocessed events (e.g. short/long press), saving a lot of code in the applications

Do we need a 'make menuconfig' for Rockbox in good old Linux spirit to enable easier custom builds?

• General consensus: No. Custom builders are competent enough to handle custom builds anyway.

Adding more big plugins/games to the single build (like Doom). Do we need to start offer different download packages somehow?

• Yes, we want to offer "light" and "full" packages for download. Light packages contain only a subset of plugins, wps:es and fonts. Plugin compatibility is maintained by publishing the date of latest plugin API revision on the homepage. We agreed that Doom is a cool thing that'll attract users so it should be added. If more huge plugins will appear, we'll decide case by case if we want them in CVS and official releases.