Plugins and keymap
2013-12-02 11:54:25 GMT
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.
All, I left a forum post generally outlining what I have in mind, but have finally brought the idea to reality and have done some initial testing to show myself it generally does what I expect. Find below a summary of what I have been hacking at. The change to the compressor revolves around making the compressor sound more natural. The point of a good compressor is to achieve an overall perception of loudness on dynamic music without making it sound unnaturally processed. My initial observation of the compressor as implemented is a sound that is distorted on the transients and mechanical on the release -- for me completely unusable except for voice recordings. For most users, I think they are just happy there IS a compressor, and that they can make dynamic music LOUD in noisy environments (such as a car). Probably some people will need to be sold on the idea that there is any need for improvement. The changes of note (to the average user) is this: Attack Time -- The goal is to preserve some dynamic life, particularly at sudden dynamic onsets. Exponential attack/release -- benefit from the natural-sounding characteristic found in analog compressors. To my own ears, the response is "alive", natural sounding. Percussive instruments become more bright, real. More details are in my commit message, and the most detail in the code, and comments in the code. There is one kludge I need to clean up, and that is the bit format. I just happened to hard-code the gain for the limiter, but I really need to have that final bit shift informed by the DSP format struct or it will be broken in any case where the bit format differs from my test case (Sansa Fuze V2, ogg vorbis format music). I mention that because if any of you try this, and it sounds either really quiet, or horribly distorted, it's because the format is different than how it is hard-coded, and for that I apologize. I will fix it in the next push if anybody shows interest in my added features. Otherwise I will probably abstain from fixing it unless I personally get into trouble with this kludge. For now, I want to stick my probes out and find out whether there is enough interest in this to make it worth my time to clean up the details (memory usage, efficiency optimizations, code formatting, etc). Thank you to any who give this a try. Best Regards, Ryan
Hi, As I don't manage to work with Git, I sent an Italian update file by Flispray. The task number is FS#12897. Could you submit it? Thanks! __________ Informazioni da ESET NOD32 Antivirus, versione del database delle firme digitali 8799 (20130914) __________ Il messaggio e stato controllato da ESET NOD32 Antivirus. www.nod32.it