Marcin Bukat | 2 Apr 20:43 2014
Picon

DevCon2014

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
Picon

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.
http://gerrit.rockbox.org/774

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

Regards,
Richard

Frank Gevaerts | 9 Feb 13:06 2014
Picon

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)

Thoughts?

Frank

[1] http://build.rockbox.org/dev.cgi

--

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

[1]: 
http://gerrit.rockbox.org/r/#/q/status:open+project:rockbox+branch:master+topic:talk-rewrite,n,z

Best regards.

Amaury Pouly | 5 Jan 15:14 2014
Picon

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

Cheers,

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
Picon

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?

Thanks,
-- 
PurlingNayuki
江   上    
----------------------------------------------------------------------------------------------------------------
請回覆至本郵寄地址
Amaury Pouly | 2 Dec 12:54 2013
Picon

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
Thomas Martitz | 1 Dec 21:49 2013

Ladies and Gentlemen

Hey folks,

this is not the usual kind of Ladies and Gentlemen mail. Instead of a 
new port I have managed to get Rockbox play sound in a new environment.

What I am working on is to to detach the playback core (including 
codecs, buffering and playlists) from the GUI and legacy OS-like 
(threads etc) environment. That means I want the playback core to work 
on native OS threads and synchronisation primitives (i.e. pthreads). I 
can say I have managed to get a few songs playing in such a environment. 
The first song of was "I Could Be The One" by "Avicii / Nicky Romero".

The code is a _huge_ hack right now (I really mean it) but I invite any 
of you guys to collaborate. I try to push some code as early as possible.

Best regards.

Thomas Martitz | 29 Nov 09:27 2013

Typedef rule

Hello,

as you know we have a "no typedef rule" in our guidelines. However there 
are a few problems with it when applied to integral types:

* Portability is reduced, for example we use unsigned for thread ids but 
pthread uses unsigned long (I have some work where we can use pthreads, 
at least in parts). This could be handled better with a typedef.
* Readability is reduced, for example we use long for our tick. IMO 
readability/expressiveness would be improved by refering to a "tick_t" 
instead of ordinary long.
* Type checking is prevented, for example gcc could do better type 
checking with proper typedefs. It's easy to think "I can use int instead 
of long" when the global tick really needs to be a long.

The Linux kernel coding guidelines have summarized the issues even 
better: https://www.kernel.org/doc/Documentation/CodingStyle (chapter 5).

Therefore I propose that we relax the typedef rule and allow typedefs 
for integral types (only) when reasonable. This would basically be 
adopting the Linux kernel guideline w.r.t. to typedefs, except they 
allow typedefs for "totally opaque objects (where the typedef is 
actively used to _hide_ what the object is)."

In essence:
  - No typedef for structs and unions. These types help with the 
aforementioned problems by themselves.
  - No typedef for pointers. Hiding a pointer between some type remains 
silly.
  - No typedef for trivial ints, like normal counters (except tick) or 
something like that.
  - Allow typedefs where reasonable, i.e. where it helps enforcing a 
specific type, improves readability and portability.
  - Allow typedefs for void, as to give "void *" a more telling type.

I'd like to trust our developers to weigh up what's reasonable.

Best regards.

Frank Gevaerts | 2 Nov 22:28 2013
Picon

Volume limiter

Hi,

We don't currently have a volume limiter option, although people do ask
for one every now and then. As far as I understand it, the usual
response is that this is easy to achieve by just setting the EQ precut.

However, while this works well for people who don't use voice, it
doesn't work for people who do, for the simple reason that voice doesn't
go through the EQ, so it will suddenly be horribly loud.

I'm suggesting that we probably should have a volume limiter option.

Thoughts?

Frank

--

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

Mat Mirabella | 30 Oct 01:31 2013
Picon

Fuse plus hissing

Hi all.

Sorry if this has been talked about before but I Just wanted to report that I am getting a loud hissing sound all the time while running rockbox on the fuse plus.  this has been the case for the last few daily builds over this week.  Does anyone else have this issue?

I realise the fuse plus port is still unstable but I wanted to report this in case someone knows about the problem - it may be something that has been seen in previous builds and it may be an easy fix.

Mat.



Gmane