2014-04-02 18:43:33 GMT
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
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 , 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  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
Hello folks, I wanted to request comments on my talk rewrite on gerrit. 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. : http://gerrit.rockbox.org/r/#/q/status:open+project:rockbox+branch:master+topic:talk-rewrite,n,z Best regards.
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.
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.
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
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.