Hi Peter,
> 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.
I'll work on getting this committed (probably today).
Kind regards,
Bertrik
Hi,
> 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. Th
...
> 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 t
On 19-7-2013 11:35, Amaury Pouly wrote:
> Hi all,
> I would like to bring back some thought on the volume handling and the
> radio.
...
> 2) Handling of radio volume
>
> This is nothing new but very annoying: some targets have limited
> amplifying range when routing from radio. It appears that for
On 19-7-2013 11:35, Amaury Pouly wrote:
> Hi all,
> I would like to bring back some thought on the volume handling and the
> radio.
>
> 1) Handling of steps
> With the recent rework of jhMikes, the internal representation of the
> volume changed: now the hardware drivers also work in tenth dB
> re
> It's me again, this time working on native stuff ^^
> Here a self-explanatory screenshot telling you that work has been done on
> a
> new target: Samsung YP-Z5!!
> This player has a STMP3650 cpu, quite similar to the STMP37xx port by
> pamaury, who in fact helped me a lot...Thanks to him, then.
>
On 3-1-2013 4:35, Scott Berry wrote:
> Hello there,
>
> I just got a Machspeed Eclipse device for Christmas. Can anyone give me
> some pointers how to find out about the OS they are using plus specs on
> processors and other items I might need to build Rockbox on this
> device? I am looking at p
On 24-11-2012 3:03, Mike Giacomelli wrote:
>
> As we've discussed before, the clip radio keymap is really confusing. I
> finally tried it and it indeed annoyed me the way its completely
> different than the way WPS works, even though its conceptually similar.
>
> I've updated a patch to correct
> The archos recorder build has tipped over the limit for size, and now the
> autobuild always fails.
>
> The tipping point was commit bd6e6ed but the code has been growing
> steadily so I wouldn't say this particular commit is any more responsible
> than others before it.
>
> Still, we need to fix
k there are any actual bugs left
(at least no extra bugs compared to the sansa clip+) that should
prevent us to release for the clip zip.
Please have a look to see if there's anything you're willing to
help with.
With kind regards,
Bertrik Sikken
codec thread
* Seeking is implemented, but does not work for all cases
* It's not realtime yet on portalplayer (e.g. sansa e200)
last time I tried
Regards,
Bertrik
On 26-7-2012 2:08, Bertrik Sikken wrote:
> Hi all,
>
> Me (bertrik) and freqmod (Frederik M.J. Vestre) have b
On 26-7-2012 8:25, Rafaël Carré wrote:
> Le 2012-07-26 14:08, Bertrik Sikken a écrit :
>> Stuff that still needs work:
>> * Memory allocation in the codec main is not fully consistent yet (probably
>> leaking some memory), so playing several files in sequence may not work
does a lot of memcpy'ing when processing a stream, also it performs
CRC checks on the data. Apparently there is a libogg2, which avoids at
least the memcpy.
* There are still some warnings emitted from the compiler.
Please try it out and help enhancing it further.
Kind regards,
Bertrik Sikken
Hi Mike,
On 6-7-2012 12:30, Mike Giacomelli wrote:
> Hi Everyone.
>
> I've implemented a new logging system for rockbox to eventually
> replace DEBUGF and LOGF. The new system is very similar to the old,
> but with 2 significant improvements:
>
> 1) It uses the register_storage_idle_func to wr
> Am 25.06.2012 00:01, schrieb Jacob Mansfield:
>> Hi All,
>> I just noticed that my Sansa Fuze errors with an 'Undefined
>> instruction at 0830' when removing the USB cable. not a major
>> problem, as holding the power button for about 15 seconds resets the
>> device, but still rather annoying
Hi all,
Last week at devcon euro 2012 we talked about pre-release testing and
I'm volunteering to help things forward w.r.t. testing.
One of the problems we've seen with the last release was that really
basic functionality like audio file playback and radio playback did
not work on some targets a
Hi all,
While debugging a problem using our shiny new ARM backtrace feature,
I noticed that by default, we're not building with -g (= include
debugging information in the binary). This means that with the
default build, I can't get the source code line from the backtrace
addresses (with arm-elf-ea
11 .
As far as I know, the only change done to this radio code, is some rework
on the power handling.
With kind regards,
Bertrik Sikken
ime
(because of bad fm reception for example).
Any ideas for changes/improvements on this proposal?
With kind regards,
Bertrik Sikken
On 21-12-2011 7:53, Boris Gjenero wrote:
> With -Wmissing-declarations, gcc can warn about non-static global
> functions and data without a previous declaration. What do others think
> about the idea of enabling the warning for the core, after some cleanup?
I am generally in favour of this.
For t
Hi all,
I'd really like see FS#12390 - Sansa Clip Zip Cabbiev2 Port getting
incorporated in SVN, however I can't wrap my head around one specific
issue:
When I create a fresh rockbox.zip file and install it into a fresh
.rockbox directory on the sansa clip zip, it appears that everything about
the
Hi all,
I noticed last weekend that the git mirror of the rockbox SVN appears to
work no longer. It seems to be stuck at SVN revision r31106.
What are the plans for this mirror?
Are we going to keep it? Or just let it die if/when we fully switch to git?
Kind regards,
Bertrik Sikken
On 5-11-2011 4:40, Michael Sevakis wrote:
>>> I think you misunderstood my point, you can implement it differently
>>> with another hardware without any problem. The proposed rds_
>>> interface doen't imply a particular way of doing things, is it ?
>
> It was not specific as far as what level had
On 5-11-2011 12:53, Michael Sevakis wrote:
> - Original Message - From: "Bertrik Sikken"
>> The Si4703 can be configured to capture one RDS packet, then
>> raise an pin voltage for 5 ms. My plan is to attach an interrupt
>> to this event that wakes up a h
Hi all,
This is a proposal for extending RDS support in Rockbox.
Since I now have a stable target with hardware that supports RDS
(The Clip Zip, which has Si4703), I can really start working on this.
* What is RDS
RDS is a system for delivering data over FM radio. It's formatted
into 8 byte pack
The Sansa Clip Zip played its first song in the evening of 2011-10-29,
the song played was Mylo - Drop the pressure.
Working code for both the bootloader and the main firmware is already
in SVN and should be relatively safe for developers.
This player is actually quite similar to the Sansa Clip+
On 8-10-2011 12:07, Ted Neal wrote:
> Just thought I would let you all know that there is a new F/W for the
> Clip+ that was just released yesterday that is incompatible with Rockbox
> as of this message. I got the .15 F/W off the google cached site to tide
> me over with Rockbox. Keep up the great
On 24-9-2011 10:32, Bertrik Sikken wrote:
> I wonder if the rockbox fund can pay for a Sansa Clip Zip, so I can do
> further rockbox development on this player.
I ordered a sansa clip zip 4gb and contacted Björn to handle the
funding details. I hope to be able to start hacking soon :D
Bertrik
Hi all,
I agree mostly with Thomas, but I can't comment on all of his points,
see below.
On 25-9-2011 4:54, Thomas Martitz wrote:
> I want to discuss that commit as I disagree with it in some ways,
> perhaps even see it reverted.
>
> Clearly it introduced a user configurable skin buffer. That is
Hi,
You might have noticed already that I'm working on a rockbox port for
the Sansa Clip Zip. This thing appears to be very similar to the Clip+
so I expect a relatively quick port. The bootloader is basically ready
for testing on an actual device.
I wonder if the rockbox fund can pay for a Sansa
>> Do we really want to allow commits directly? so little of our code ever
>> gets
>> reviewed so I would quite happily force everyone to go through gerrit
>> and
>> require someone else to OK it. It isnt hard to get someone else in IRC
>> to have
>> a quick look and push the button.
>
> Absolutely
> On Mon, Aug 22, 2011 at 7:32 PM, Jonathan Gordon
> wrote:
>> What has how you set it got anything to do with it being a setting or
>> not? Time does not magically change when you give your DAP to your
>> sibling.
>>
>
> No, but it changes when you enter another time zone. Or daylight
> savings c
also add "dB"
after the number for targets that have enough room.
With kind regards,
Bertrik Sikken
On 24-10-2010 11:18, Bertrik Sikken wrote:
> Hi all,
>
> I'd like to propose a new feature:
> received signal strength indication (RSSI) for fm radio
Basic support for RSSI has now been committed.
The minimum, maximum and current RSSI level can be queried from the
radio driver
On 8-11-2010 2:16, Teruaki Kawashima wrote:
> Hi,
>
> I'd like to ask for testers for FS#6321 - Universal Image Viewer
>
> The patch unifies jpeg viewer, png viewer, and bmp viewer to one plugin,
> image viewer so that you can navigate through different image formats.
> Downside might be that the
> Hi,
>
> Are there fundamental reasons not to commit FS#8806? I know that ideally
> we want all sound formats to play via a codec and not a plugin, but the
> way I understand these tracker formats, the codec buffer size would
> really limit the usefulness of such a thing.
>
> This patch has been o
> Hi,
>
> Are there fundamental reasons not to commit FS#8806? I know that ideally
> we want all sound formats to play via a codec and not a plugin, but the
> way I understand these tracker formats, the codec buffer size would
> really limit the usefulness of such a thing.
>
> This patch has been o
> I would like to see them stable and be part of 3.7. Rockbox is very
> stable on my fuzev2. Is there anything blocking them? FWIW I don't think
> missing USB is a blocker.
One thing not working properly on these targets right now is that the
RTC wakeup feature. Under certain circumstances, the pl
On 25-10-2010 11:07, Thomas Martitz wrote:
> On 19.10.2010 17:58, Jonas Häggqvist wrote:
>> On 19-10-2010 12:07, Thomas Martitz wrote:
>>> So I uploaded my kinetic scrolling patch.
>> [snip]
>>> I guess I can commit in a week if I get a) enough votes or b) nobody
>>> cares
>>> at all?
>>
>> How abo
On 25-10-2010 8:31, Marcin Bukat wrote:
> 2010/10/24 Bertrik Sikken :
>> Hi all,
>>
>> I'd like to propose a new feature:
>> received signal strength indication (RSSI) for fm radio
>>
>> This makes it possible to show an indication of the radio signal
&
sible tuner-specific minimum and maximum RSSI values are #defined
and accessible through tuner.h
Steps 2) and 3) are yet to be done.
Please let me know what you think.
Kind regards,
Bertrik Sikken
On 11-9-2010 10:13, Trevor Halsey wrote:
> I recent bought the iPod Radio Remote accessory and was thrilled to see
> that it was supported in rockbox but then I went to use it and realized
> the radio was useless in rockbox unless you were recording. When I go
> into the FM Tuner and choose a sta
On 7-10-2010 11:04, Marianne Arnold wrote:
> Am 07.10.2010 10:11, schrieb Alex Parker:
>>
>>
>> What actually are these? Does anyone know if there are any relevant
>> bug reports?
>>
>> Alex
>
> Yes, there are: http://www.rockbox.org/tracker/task/11591 and a few
> people (including devs) reported
Hi all,
The AMSv2 players currently play back audio with quite a big pitch
and speed error. They play about 1.1% too "flat" and slow. This is
big enough for quite a few people to notice it, see for example the
anythingbutipod and head-fi forums.
This playback error is the result of how the playba
On 15-6-2010 11:33, Rob Purchase wrote:
> On 15/06/2010 11:17, pouly amaury wrote:
>>
>> You convinced me that finally think that I should (or someone else !)
>> rewrite it in assembly to avoid any further problem. Any one against
>> that ?
>
> This version seems to work correctly:
>
> static inl
On 8-3-2010 3:15, Thomas Martitz wrote:
> Hello,
>
> I've uploaded my latest test results with gcc 4.4.3 and the just
> released binutils 2.20.1 to
> http://www.rockbox.org/wiki/CodecPerformanceComparison. The new combo
> does a bit better than the current 4.4.2/2.20 combo (reading the
> binutils
On 10-1-2010 3:37, Rafaël Carré wrote:
> Le 10/01/2010 15:24, mai...@svn.rockbox.org a écrit :
>> Date: 2010-01-10 15:24:45 +0100 (Sun, 10 Jan 2010)
>> New Revision: 24211
>>
>> Log Message:
>> Sansa AMS: allow use of PLL B for more accurate audio sample rate (0.04%
>> instead 0.15% error)
>
> Do
On 28-12-2009 11:47, Bertrik Sikken wrote:
> There is even a special macro to mark a menu as an "onplay" menu.
> I actually tried to make this more consistent (it was easily possible
> to make it completely consistent) in FS#9037
I meant to say "it was NOT easily possib
On 27-12-2009 4:25, Paul Louden wrote:
> Apparently within the WPS context menu some submenus (for example, sound
> settings) can be entered and exited without leaving to the WPS.
> Meanwhile others (like Playlist) cannot. Attempting to leave them by
> pressing "left" will take you to the WPS again
Hi all,
Here's a short status update on the Meizus (M3, M6SP, M6SL):
* The Meizu M3 port is the most advanced of the Meizus right now,
display output works and we can compile and run a bootloader binary
(it doesn't actually boot or load anything though...). A lot of
progress was made just af
... we have sound on the Meizu M3!
The sound was the first two seconds of "On my way" by Giovanca, as a raw
wav statically compiled in the Meizu bootloader (we can't run a "normal
rockbox" yet on the Meizus).
So, it's not a full song yet, but it does prove that the audio codec
communication, PCM
Jonas Häggqvist wrote:
Bertrik Sikken wrote:
How about the following settings:
Europe: 87.5 - 108.0 MHz, 100 kHz steps, 50 us de-emphasis
US / Canada: 87.9 - 107.9 MHz, 200 kHz steps, 75 us de-emphasis
Japan: 76.0 - 90.0 MHz, 100 kHz steps, 50 us de-emphasis
World: 87.5
Daniel Stenberg wrote:
So, feel free to reply to this mail (to the dev list please) or start
hacking on a wiki page.
How about a project to rework the radio screen?
In its current shape it looks very basic.
A student could design a new interface for it that is a bit more visual.
Or possibly, s
Alessio Lenzi wrote:
"Mike Holden" wrote:
boundary where it can be squeezed in.", suggesting that this is not
exclusively Italy, but possibly other countries as well.
european standard is 50, also the official Sansa's E200 firmware, by
setting Europe, lets skip 50 MHZ only.
Besides I bought
Mike Holden wrote:
Bertrik Sikken wrote:
Hi all,
While working with the rockbox radio code a bit I noticed that currently
the FM channel spacing for the 'europe' FM region setting is 50 kHz.
(see fm_region_data in firmware/tuner.c)
I think this should be 100 kHz.
The 100 kHz s
Hi all,
While working with the rockbox radio code a bit I noticed that currently
the FM channel spacing for the 'europe' FM region setting is 50 kHz.
(see fm_region_data in firmware/tuner.c)
I think this should be 100 kHz.
The 100 kHz spacing for europe is mentioned in the si4702 radio chip
dat
Robert Menes wrote:
On Tue, Dec 16, 2008 at 10:03 AM, Björn Stenberg wrote:
Are there more settings we should look into?
"Repeat All" doesn't have to be set on by default. "Repeat" should be
set to "off"
on the first startup.
I agree on this one.
It's happened to me quite a few times that
Michael Sevakis wrote:
3) There's a huge chunk of code (charging_algorithm_big_step) that
only gets used when CHARGING_CONTROL is defined. This seems to be
some kind of -dV/dt charging algorithm.
Can't we move this to a separate file?
We could (for example) move specific charging
Hi,
How about we clean up powermanagement.c a little further?
After looking through the code, I have some suggestions:
1) There seems to be some low-level battery voltage logging in
powermanagement.c when DEBUG_FILE is defined. Do we still needs this
or can we remove it and just use batter
alex wallis wrote:
Hi. I just noticed what i'm thinking might be an option that can be got
rid of in the system menu.
in the system menu there is an option called version, this option isn't
voiced. however under rockbox info, the version field is voiced, so I
was just wondering is there really
Hi all,
I think there's a problem with the unregister_ata_idle_func function,
which is probably responsible for "event xxx not found" panics, like
the one in http://www.rockbox.org/tracker/task/8993
The problem is that ata_idle events are registered as one-shot events
which clear themselves once
Hi,
Is there a policy or common understanding on "DO's and DON'Ts" for
header files in rockbox?
I'd like to propose the following:
(which I intend to be basically consistent to what is currently used)
1) use of #include vs. #include "xxx.h"
Use #include only for "standard library" header file
Burelli Luca wrote:
On Sat, 12 Jan 2008, Catalin Patulea wrote:
- I believe (correct me if I'm wrong) that, in general, power
consumption is proportional to the core frequency. Let the power
consumptions of the cores be P_1 = k*f_1 and P_2 = k*f_2.
An accurate estimation of power consumption
63 matches
Mail list logo
