Rockbox Progress [ANNOUNCEMENTS ONLY - NO DISCUSSION]

[Febs]

Since Rockbox has achieved almost the same level of functionality on the H300 series as on the H100 series (with battery efficiency being the notable exception), most Rockbox progress announcements relate to both platforms. I have started this thread to replace the separate H100 and H300 series Rockbox announcement threads.

PLEASE NOTE THAT THIS THREAD IS FOR ANNOUNCEMENTS ONLY! Any posts made in this thread that are not announcements will be deleted immediately and the poster warned.

[Febs]

According to this thread in the Rockbox.org forum, WMA support is close:

Originally Posted by Marsdaddy

Re: WMA again
« Reply #42 on: May 10, 2006, 07:47:16 AM » Another update for all those wondering where this has got to...

Today I decoded a WMA file on my H300 via a plugin I've written

That's the good news, two current issues: -

1) The decoder is not accurate enough - I sort of knew this but wanted to carry on with getting the WMA decoder working in the simulator and H300 first. I have a plan for tackling this as I can debug another WMA decoder etc. etc.

2) The decoder is sllllloooooowwwww... too slow. Good news is there are a number of places in the code that optimisations can be made.

I will tackle issue (1) first then optimise the fixed version

As always, when there is something to tell you I will post here

[XavierGr]

As of now the iHP-100 series supports SPDIF recording through Rockbox!
As the message suggests, please test thoroughly.

Optical S/PDIF recording and monitoring for Iriver H1x0. Removed unsupported recording options on Iriver. Sample rate displayed in recording screen reflects the real S/PDIF sample rate when doing S/PDIF recording. Testing would be appreciated. Thanks to Jens Arnold for fixing the DMA hang issue. Will reset settings!

[bagder]

Do note that we've moved out the fonts from the "regular" zip package and they are now provided in a separate font package on the daily build page.

People who build their own from sources can still do 'make fullzip' to create a full zip in the old style.

[XavierGr]

Greast news for H300 users!

From the IRC logs:
[22:56] * amiconn succeeded in locating the heat source on the H300 pcb when running rockbox
[22:56] <amiconn> Unsurprisingly, it's the ISP1362
[22:56] <Genre9mp3> \o/
[22:57] <egotrippen> \m/ \m/
[22:57] <amiconn> 7 °C more than its surroundings
[22:57] <amiconn> ...even more than the CPU
[22:57] <amiconn> (which runs a bit cooler under rockbox than under retailos)
[22:58] <amiconn> The ISP1362 stays at environment temperature under retailos...
[22:58] * amiconn should probably try USB host mode under retailos
[22:58] <petur> bingo

Seems that amiconn managed to discover which component consumes more power than needed (thus lower battery times in Rockbox)

Now sit back and wait for a fix commit.... (until code is written to prevent that behaviour)

[XavierGr]

Again great news for the power issue on H300!

From the IRC logs:
[03:46] <amiconn> w0000000000000000000 0t !!!!
[03:47] * amiconn has contact to the isp1362
[03:47] <midkay> amiconn, great, congrats.
[03:47] <amiconn> ISP1362 HC ID: 0x3630
[03:47] <amiconn> ISP1362 DC ID: 0x3630
[03:47] <amiconn> Now we can try to send it to sleep...
[03:48] <amiconn> ...but before doing so, I need sleep :/


[03:48] <amiconn> We need to stop it from sucking battery
[03:49] <amiconn> midkay: USB on the go
[03:49] <amiconn> The problem was indeed a really fundamental one

<amiconn> We do want to support usbotg one day, but if the chip is not in use, it should be put to sleep
[03:54] <amiconn> The chip sucks power in the same order of magnitude as the CPU, thereby almost halving battery runtime on H300
[03:55] <midkay> amiconn, right, should certainly be disabled while it's not in use..
[03:55] <amiconn> I'd expect >19hours, but get 11 hours
[03:55] <amiconn> (stock battery)

That's all for now, hopefully it will be fixed soon....

[Yngwiejo]

The commit all the H300 users were waiting for...

16 Jun 19:34 Jens

H300: Rudimentary driver for the ISP1362 USB on-the-go controller. For now it just sends the chip to sleep, solving the poor battery runtime issue.

[Febs]

The Rockbox feature freeze has been lifted, according to this e-mail from the Rockbox developers list:

Originally Posted by B. Stenberg

Hi all.

It is with mixed emotions I hereby announce that the feature freeze for 3.0 is now lifted -- without 3.0 having been released.

We have been in freeze for over three months now. And we have indeed fixed many bugs, but we still have critical problems that prevent a 3.0 release. With summer in full swing and many core developers away on well-deserved holidays, it is impropable that these problems will be fixed before august, which would mean four months of freeze. A third of a year.

That's not fun.

I, Linus and Daniel discussed the freeze over lunch today and decided that in this difficult situation, we need to focus on the core values: Rockbox is about having fun. Being in freeze with no clear end in sight is a drain on morale and enthusiasm, which is not how we want Rockbox to feel. So we decided to end the freeze now and unlock the doors to creativity and programming joy.

At best, we'll get lots of new improvements and exciting features without much negative impact. At worst, the changes will destabilize the code base severely and push the prospect of a 3.0 release even further into the future than today. In order to hedge our bets, we have set a tag in CVS which we can return to and branch from if we later fix the critical bugs and would like to release Rockbox in today's state.

We still think the freeze was the right decision. We just weren't able to reach the state we wanted to, in the time we wanted to. And rather than stubbornly repeating "we freeze until release", we adapt to the current reality and unfreeze.

Gentlemen, start your compilers.

--
Björn

[Mike]

5 Aug [various developments]

Initial support and use for EEPROM memory on H120 & H140 players when Rockbox firmware has been flashed over original firmware (not yet possible to do). Dircache & tagcache serialization for fast bootup without the need to scan disk when Rockbox is in flash.

Initial version of the iriver flashing plugin for H1xx. Building of the code not yet enabled, because the code still lacks some features and safety checks.

Initial EEPROM driver for iriver H1xx.

[jewman]

Initial commit of work-in-progress MPEG video player plugin based on libmpeg2. Works on all targets with colour LCDs, but most optimised for the ipod Color/Photo and Nano. It currently only plays raw MPEG-1 or MPEG-2 video streams (no audio). Also adds a new lcd_yuv_blit() function to the plugin API - currently only implemented for the ipod Color/Photo and Nano.

Basically this means that we are one step closer to video on h3xx (and hopefully h1xx).

[Febs]

linuxstb posted this message on the Rockbox forums, giving a good explanation of where video stands and what you should and should not expect from video on iriver players:

Originally Posted by linuxstb

This post doesn't belong in this iPod Video forum - the mpegplayer now in CVS is implemented purely using the CPU, and not using the iPod Video's Broadcom chip. Hopefully this thread will be moved, so I'm posting a little status update here.

I own an ipod Color, and the Photo/Color and Nano share the same LCD driver, which is why those targets have received the first optimisations. I also own an ipod 5g, and will be working with that as well.

All ipods (with colour LCDs) have a more or less identical main CPU (the PortalPlayer chip), which means that out of those targets, the Nano is most likely to get working video support first - a full-screen video on the Nano is only 176x128, compared with 224x176 for the Photo/Color and 320x240 for the Video. So there is both less data to decode, and less data to write to the LCD.

Currently, the player can play back a 176x128 MPEG-2 file at around 24fps on the ipods - so this means either full-screen on the Nano or smaller than full-screen on the Photo/Color and 5g. Full-size videos on the Photo/Color and 5g play much slower than that. The aim is to get this up to at least 25fps (PAL framerate) and hopefully 29.97fps (NTSC framerate) for full-size video on all targets.

The PortalPlayer chips inside the ipods have two 75Mhz ARM cpu cores. Currently the video player (and Rockbox in general) is just using one. The hope is that if one core can cope with full-speed video decoding (and writing to the LCD), the other core can be brought into use to handle the audio decoding, buffering the data from disk, and whatever else a video player needs.

Things are not looking as bright on the Coldfire-based targets (iriver H300 and iaudio X5) - full-screen video is around 9fps on the H300 at the moment when running the CPU at the full 124MHz. And there is no second core to use for audio - the main CPU will need to handle everything. But these are early days - all the audio codecs were also worryingly slow when first run on the Coldfire. I personally will probably not be working on the Coldfire version (I don't own a H300 or X5), so developers are needed...

[Mike]

Lots of developments.

12 Aug

Enabled iriver flashing plugin with additional safety checks, confirmation and ability to restore original firmware

Committing FS#5182 - One button hold for Horizontal screen scrolling. =>hold RIGHT or LEFT button on a GUI based list to scroll horizontally

Better UI response with playlist operations

Fixed track order when inserting an album from tagcache to the playlist with "insert next" or "queue next".

[Mike]

From earlier today, as requested by people for the WPS:

Allow scrolling lines with different x-margins. The margin at the time of the call to puts_scroll will be used as the margin for that line.

[Tech_Cowboy]

From the change log:

Added FS#2939 Encoder Codec Interface + Codecs by Toni(ahellman) with addition FM Recording support.

Gentlemen, we have MP3 recording.

TC

[crazy_bob]

Apply a bunch of simple AAC decoder optimizations. Biggest speedup is on ColdFire targets, but ARM targets benefits too. Allows realtime playback of some AAC files on Iriver targets (H1x0, H3x0). Remove support for some rarely used AAC profiles to reduce code size a bit.

Now aac files are running on realtime. Smooth

[rasher]

Today Tag Cache was renamed to simply "Database". You'll need to rebuild your database (or rename all files starting with tagcache in .rockbox to use database instead).

[Landus]

USB charging for the h300 series was added on February 3rd.

Holding down the record button while plugging in the player will keep it from docking and just charge.

[Mike]

Cover art displays now are possible on Rockbox, in the committed code (i.e., not only by way of a patch).



However, as best I can tell, setting margins for text to appear to the side of cover art is not yet possible in the committed Rockbox code (although there are a couple of patches out there to do this)--my best guess is, that will be up next for committing to the code, if possible, making cover art very practicable.

[Mike]

Dang, I got that one: just committed, a scrolling text left margin setting command. Note that this does not allow the right margin to be set and so, when used with album art, the album art will be in the left position. Looking forward to all the cover art WPSs to come (including for the H1xx player ...)!

[Mike]

Major WPS developments with Rockbox the past few days:

-- Viewports has now been committed, allowing the use of precise positioning of information on the screen.

-- Bitmap strips has been committed, vastly increasing the number of images that are possible in a WPS.