Peter | 23 Jul 08:48 2014

slovak lang update

Hello All,
I am very sorry that i am doing lang update  in this way, I totally
forgot my login data to patchtracker. Attached is Slovak language update.
With best regards
Copyright by individual Rockbox contributors
for details.
May be distributed under the terms of the GNU GPL version 2 or later
This file generated by

This translation was based on git hash 43e52e34ed7c9a9b08ab706b75dd608f53d0b4cc of the original.

--- apps/lang/slovak.lang	2013-07-16 06:13:06.000000000 -0700
+++ apps/lang/	2014-07-22 23:44:58.000000000 -0700
 <at>  <at>  -12265,15 +12265,15  <at>  <at> 
   user: core
     *: none
-    gigabeats: "Band %d Gain"
+    gigabeats,samsungypr1: "Band %d Gain"
     *: none
-    gigabeats: "Šírka Pásma %d"
+    gigabeats,samsungypr1: "Hlasitosť Pásma %d"
(Continue reading)

Jonathan Gordon | 3 Jul 15:21 2014

Please help test gerrit#890

Hi all,

Over the last few days I've been working on redoing how the skin engine manages its buffers. My goal is to finally get rid of all the semi-random skin issues and this is the first step.

This patch adds some error handling and will also make any issues blow up in a more debug-able way (hopefully a data abort!).

This first version should work with all tags except the skinned lists (which hasn't seen much use anyway) but that will happen over the weekend.

A side benefit of this is a slightly smaller binary (seems to be about 5K smaller on the ipod video build).

Please let me know if you find any crashes - or even better if this fixes any crashes with your troublesome skins!

Thomas Orgis | 19 Jun 08:19 2014

Extending the metronome plugin


I would like to start a new attempt at improving the metronome plugin
in Rockbox. There are two main points:

1. Support config files with programmed songs (sequences of patterns
with different meters / tempi). I guess it would make sense to use the
"tempo map" format of for this.

2. Have an optical mode, flashing the display (or parts of it) instead
of or in addition to playing a sound.

An Editor for these tempo maps inside the plugin would be bonus, but
for starters I would consider the maps coming from elsewhere. My
platform is a Sansa Clip+. My questions for the seasoned Rockbox devs
are these:

1. Is there an API call to get a file selection dialog or should the
plugin instead register as handler/codec for tempo map files to be started
from the main "files" menu? Excuse me for not finding that answer
myself, I didn't find an obvious place where API/plugin design is
documented. Pointers welcome, of course.

2. Is using the display as flashing indicator LED feasible? I guess it
should be for the Clip+, as it's just a little grid of OLEDs. But the
question would be if it can be done quickly in a timely manner to serve
as metronome (thinking of switching the whole upper or lower half for
opposing tick/tock). Since there is no background illumination, it
should be rather power conservative to have all black pixels most of
the time, right? And regarding the speed/latency: I remember running
Doom on that display, so that should technically work;-)

I'm a seasoned C developer (some might recognize me for maintaining
mpg123 over the last 8 years) and am confident to get the job done for
giving Rockbox an awesome metronome, once I got the starting points. I
did read the source of the existing metronome plugin and would start
from there.

Alrighty then,

Marcin Bukat | 18 Jun 08:13 2014


Hi rockboxers!

There have been long time since we did 3.13. We are in the state where first thing we advice when someone pops up with problem is to install development build. Moreover there are quarrels among devs comming from the fact that we are not in feature freeze but some think we should be. The only solution IMO is to do release outright. The commit rate is low and this are mostly fixes. Current builds seems to be in good shape. Having release would allow us to integrate quite invasive synopsys patch which would bring us back usb on nano2g and classic. Now the question comes - do we still have release manager (Alex?)

Marcin Bukat (wodz)
Marcin Bukat | 2 Apr 20:43 2014


Hi chaps!

Last year we missed DevCon oportunity, it would be a pitty not to meet You again this year. I'd like to offer hosting of DevCon in Warsaw Poland. If You find it interesting we should start thinking about suitable date. Looking forward for feedback.

Marcin Bukat (wodz)
Richard Quirk | 23 Mar 18:30 2014

Updating Lua plugin to upstream 5.2.3

I've updated the Lua plugin code to use the upstream 5.2.3 release.
For comparison, the current code uses Lua 5.1.4.

It's quite a large change, though mostly due to changes in the core
Lua code. I've tried to minimise the differences between Lua upstream
and modifications for Rockbox, while also trying to keep churn between
what we had before and this new version to the strictly necessary.

I've tested this on a clip zip and in the simulator.


Frank Gevaerts | 9 Feb 13:06 2014

Archos devices: time to let them rest?

Hi all,

When rockbox started about twelve years ago, the Archos Jukebox was
still a shiny new device, only slightly outclassed by the Recorder with
its wonderful bitmap display.

Rockbox pushed these devices far beyond what anyone could have imagined
when they were released.

Rockbox now runs on many more devices than these old Archoses, and with
each new device, new challenges and opportunities arose. We now support
colour screens, CPU decoding, touchscreens, and many features that were
inspired by new and more powerful hardware.

These newer devices are now vastly more popular than the Archoses, and
this combined with the Archoses being different in some important ways
(using a hardware codec, and for the Jukebox, using a character cell
display) has meant that during the last few years Rockbox for the
Archoses has not had the maintenance it really needs. This is e.g.
visible on the build page [1], where you can see that the build for the
Archos Recorder has been broken for more than a year, due to it (and
soon, probably, some of its siblings) really needing to move to a
different way of booting (a move the non-Archos ports made back when
they started).

The work needed to keep the Archos port alive is not impossible, but at
least for the past two years, nobody has stepped up. We don't even know
if anyone still has one of these devices in active use.

I think it's now time to let the Archos port rest. Without it, rockbox
would not have existed, but the way we treat it currently is not what it
deserves. We don't want people to Rockbox on the Archoses as an
annoyance that keeps breaking the build.

Let us try to remember Rockbox on the Archos in its glory days, when it
showed the world what a digital audio player could really do.

I propose we let 3.13 be the last rockbox release that supports the old
Archos devices, and that we won't try to force them into the 3.14
release again.

I also propose we stop auto-building the Archos ports right away, and
that we consider any HWCODEC or CHARCELL code to be available for
cleanup after 3.14 has been released (such cleanup can destabilise the
code, and we want 3.14 out soon)





"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Thomas Martitz | 21 Jan 23:58 2014

talk rewrite

Hello folks,

I wanted to request comments on my talk rewrite on gerrit[1].

For this who haven't heard about it yet I'll summarize what it is about:

I found that the cache management for TALK_PARTIAL_LOAD is immensely 
inefficient. It allocates 64 slots for talk clips, each as big as the 
biggest clip in the voice file (such that any clip will fit into any of 
these slots). But the biggest clip can be easily more than 3x as big as 
the average which results in a major waste of RAM.

My rework changes the cache management to use buflib for it. With buflib 
a max. buffer size (currently 100k) is specified and buflib will load as 
many clips as possibly fit (most memory efficient), one buflib 
allocation per clip. Buflib natually keeps this cache compact as newer 
clips replace the least-recently-used ones. Other implications of buflib 
apply, such that the clips can move during compaction, which is a 
problem for DMA access on hwcodec. Therefore clips will be copied to a 
small static buffer (1k) before decoding, to keep things simple.

Note that this is not to be confused with that the clip cache itself is 
a buflib allocation which is already in git master. This rewite uses a 
nested buflib instance to load clips into the large clip cache buffer.

Later commits apply this new clip management to be also used for 
!TALK_PARTIAL_LOAD and even for the thumbnails (for dirtalk), so that 
there is only a single algorithm for all kinds of clips and targets 
(!TALK_PARTIAL_LOAD still loads the entire voice file into RAM but uses 
the same code to access each clip).

Some numbers to see the effect: On the clipv1 caching 64 clips of 
english.voice required almost 300k. The code now uses a 100k buffer 
which fits ~60 clips on average. For german.voice it previously used  
~390k for 64 slots whereas the new code fits 54 clips into 100k. Note 
that 390k is a significant share of the total RAM available on the clipv1.

In essence the rewrite is a huge win for lowmem and also achieves a more 
unified code in talk.c across targets and clip types.

What do you think? Please commit.

I would like to push this fairly soon, unless some speaks up. I tested 
on e200, clipv1 and Player.


Best regards.

Amaury Pouly | 5 Jan 15:14 2014

Ladies and gentlemens, we have sound on the Creative ZEN X-Fi Style

I'm pleased to announce that Rockbox successfully played its first track on the Creative ZEN X-Fi Style: PrototypeRaptor - Drive Hard

The port was completely trivial except for a little quirk with the MBR handling, so I did it mostly for free. There are two kinds of LCD so I obviously could only test one of them. Dual boot has not been attempted but I don't expect any issue here. Speaker is not handled for the same reason it is not on the others (lack of framework in Rockbox) but I'm working on it.

The players looks nice except for the annoying lack of hold button and the small buttons. It can also do TV-out in theory. Also contrary to older other Creative players, this one can easily be supported by Rockbox Utility, just like the Fuze+.


NOTE: I have not forgot the ZEN (X-Fi, MX) users, I'm still stuck with some LCD and power issues on those devices.

Amaury Pouly
PurlingNayuki | 23 Dec 15:15 2013

G#697: New Volume Limiter feature for Rockbox (gerrit reviews and codes improvements needed)

    To prevent some unexpected volume change, I implement a Volume Limiter feature.
    I add a "volume limit" parameter to the configuration file. Each time when WPS_VOL_UP or setvol() is excuted, Rockbox will check if the global_settings.volume value larger than global_settings.volume_limit. If larger, take the value of volume_limit instead.
    I also have some question and when coding, and helps are appreciated:
- Can INT_SETTING_NOWRAP() macro accept only CONST as its max, min and default parameters?
- How can I get the maximum and minimum volume value in settings lists?
- How does volume changing work in Rockbox?

江   上    
Amaury Pouly | 2 Dec 12:54 2013

Plugins and keymap

Hi All,
I'm sorry to brought up this painful topic once more, but I feel I need some solution here and some feedback. 
The issue is that at the moment I have ports in progress: Fuze+, ZEN, ZEN X-Fi, ZEN Mozaic, ZEN X-Fi2, ZEN X-Fi3 and NWZ-E360/E370. If you do the math, removing touchscreen targets and so on, that's at least 3 very different keymaps (+variants). Doing the keymapping for Rockbox itself is already quite a thing but doing it for the plugins is just a nightmare at the moment, it takes a *huge* amount of time and one cannot enable the plugins without fixing all of them, which is unfortunate.
I see a few things to do at the moment, like conversion some old-time resistant to pluginlib (yes battery_bench I'm pointing at you) but we all know pluginlib just cannot be used for everything.

First off, if you have any magical solution, please tell me. Second, I suggest we apply one or more of those suggestion:
1) Come up with a whitelist to disable some plugins, so that one can compile only plugins which can be run/have a keymap
2) For plugins for which it is suitable, add a pluginlib fallback which can provide a minimal set of functionality
3) At the opposite of 1), have not-yet-mapped plugins display a message on launch saying that they have not been mapped yet and help is wanted
4) Augment the "plugins" setting configure to have three possible values: "" meaning none, "yes" meaning all and "pla" to only compile the plugins using pluginlib.

What do you think ?

Amaury Pouly