All Projects

This patch changes the IRAM usage to speed up FLAC multichannel decoding especially on targets with large IRAM. Multichannel testfiles can be found here: download.linnrecords.com/test/flac/surround88.aspx and download.linnrecords.com/test/flac/ForUntoUsSurround88.aspx

surround88:
iPod Video (PP5022) 28.3 → 25.7 MHz (svn / patch)
iPod nano2G (SL5870x) 33.6 → 27.3 (svn / patch)

ForUntoUsSurround88:
iPod Video (PP5022) 101.7 → 98.7 MHz (svn / patch)
iPod nano2G (SL5870x) 97.6 → 90.2 (svn / patch)

I would like to have some measurements for MCF5249 and MCF5250 before submitting this.

The attached patch implements multichannel-to-stereo downmixing for flac. For this all channels need to be decoded and saved in a dedicated sample buffer. For each channel configuration (3.0, 4.0, 5.0, 5.1) there is a matrix for the downmixing defined and applied.

The following file very clearly proves and shows the effect of the downmixing: http://download.linnrecords.com/test/flac/surround88.aspx

The sim for iPod nano2G (win32 cc under Ubuntu) does not compile for me with current svn (r31136). I get “undefined reference to ‘_lcd_blit_yuv’“.

The attached patch solves this issue for the sim build but results in a build error for the target.

Some more details:
i586-mingw32msvc-gcc 4.2.1-sjlj (402)
i586-mingw32msvc-ld 2.20

When connecting USB while playback the device is either crashing or locking up. This is not happening when connecting USB after a clean boot.

I observed that the HDD-icon on my WPS shows activity when skipping between buffered songs. Bisecting shows this came in between r30580 and r30590 – most likely the font buflib commit is the relevant change. As this behaviour results in a spin-up of HDD’s with a track change this might impact the battery runtime.

I have attached my WPS as this might be needed for reproduction.

Since r30546 my iPod Video does not connect via USB when running rockbox. The emergency diskmode works fine, r30545 works as well.

Since r30478 my own WPS is not loading anymore, cabbiev2 works fine. This is with a simulator for iPod nano 2G. The output of the simulator says: <Unable to load font 3: ‘13-arialbd.fnt’>

The attached patch fixes the issue for me. It enlarges SKIN_FONT_SIZE.

mokmod is configured to be build with ‘-w”. Therefor lots of compiler warnings are suppressed. This patch disables ‘-w’ and resolves all compiler warnings. At least 1 bug has been resolved through this as well: in load_gt2.c loadChunk() an out of bounds access was found, casued by writing to the wrong address.

Edit: I have attached two files (1x XM, 1x IT) for test purposes. Both play fine on my simulator.

The attached patch changes the makefiles for plugins, codeclibs and codecs/lib/tlsf to not use ‘-ffunction-sections’ and ‘-fdata-sections’ for simulator builds. This removes several warnings when compiling in my environment (Ubuntu + mingw32).

This needs a review, I am not sure whether I am detecting simulator builds 100% right via “ifdef APP_TYPE”.

The attached patch enables “-fgnu89-inline” when compiling both MPEGPlayer and Doom. This resolves several warnings I still experience in my compile environment (Ubuntu + mingw32).

Any comments?

The attached patch adds embedded album art for ASF. I am not 100% glad with the implementation as there ares till some magic numbers left. Also I cannot really test this on a large number of files with embedded jpg’s yet.
I would be glad to have some testers for this patch.

This patch resyncs libmusepack to r475 of the mpc-svn (svn.musepack.net). Exception is the buffering and seek handling (mpc_demux_fill() and mpc_demux_seek()) which has been optimized and debugged for rockbox.

Changes were mostly in the area error handling.

The following patch adds support for embedded album art to APEv2 tags. The parser supports both “.jpg” and “.png” format even though rockbox will only show pictures encoded in jpg-format.

Playlist re-shuffle does not work anymore. I go into the DB, select “Track” and play from one of tracks in there. Then I go into the WPS context menu (longpress select), go to “Playlists” and select “Re-shuffle”.

Expected: The current title keeps playing. The playlist itself is shuffled.

Observed: The current track keeps playing, the playlist does now only contain the current played track.

In v3.9 this works.

The attached patch moves several additional data arrays to IRAM for MCF5250, PP5022 and PP5024. It also enables the usage of the configuration for large IRAM on S5L870x (how could I oversee this…).
I will measure the impact on performance on PP5022 and S5L870x tomorrow. Maybe someone else can measure the effect on MCF5250.

This patch moves a few arrays to IRAM and makes use of MEM_ALIGN_ATTR. Performance is slightly increasing on iPod nano 2G (+1-2%) and stable on iPod Video. I would like to see a test on Coldfire targets as well.

During measurements of the memory layout of the aac-decoder I recognized that several of our codecs do merely use IRAM (see http://www.rockbox.org/wiki/CodecMemoryUsage) – at least on iPod Video.

The attached patch moves several arrays to to IRAM. It would be great if somebody with some test file for those format could make a performance test. Maybe it is also possible to attach small samples to this flyspray entry.

This is the 2nd part of adding a metadata section to the manual. The new subsection includes two tables to visualize the featuresset that is supported by our metadata parser for a) generic metadata tags (like ID3, APE, Vorbis, MP4, ASF) and b) codec specific metadata (like supported for .tta, .mod, etc).

Next steps will be to add important limitations of our parsers. In the forums questions about limited string lengths for comment or artist names are raised.

This patch makes codecbuf[] and codec_size static within codecs.c It removes the “external” decalaration and adds a function to get the required access (only one usecase).

I experienced several hangups during playback in the middle of tracks. Those hangups appeared nearly each 1h of playback. Seek fwd/rwd or play/pause does not solve the issue. Skipping forward lets the next track play normally. The track that formerly hung up can be played normally after a skip.

Player: iPod nano 2G
Tracks: mpc / mp3

Hangups occured with mpc only, but that might just be an effect of my music collection which mostly consists of mpc.

Thread states:
codec *R 16 16 11% (⇒ always *R, not alternating *R/T)
audio T 15 15 57%
buffering T 15 15 25%

I will attach the .config file later.

I have the impression that a reasonable amount of questions in the forums comes from rockbox’ metadata implementation. This is why I want to add a metadata section to the manual. This first patch adds such section and provides a table with information about what metadata tag type is used for which file extensions.

Next steps:
- feature overview (e.g. which tags support replaygain, embedded album art, … in rockbox)
- limitations (e.g. max string lengths)

When using “-Wunused-but-set-variable” there occur several warnings when building rockbox. This patch resolves the most of them.

Please review and give feedback – especially to the change to ffmpeg_get_bits.h as this gives the most overall warnings.

Magnus Holmgren reported compiler warnings with GCC 4.6.0 in libfaad/decoder.c since r29778. The multiple warning starts at line 605: “warning: array subscript is above array bounds [-Warray-bounds]”

Reason for this is that I reduced MAX_CHANNELS to 2 (= stereo). The reported section in function create_channel_config() accesses channel_position[] at too large indices.

I reviewed the code and did some changes:
1) comment create_channel_config() as this is only used to set variables which are not used later
2) let NeAACDecInit() and NeAACDecInit2() return an error if more than MAX_CHANNELS channels are recognized

The attached patch removes malloc from the libfaad codec. The patch works fine on simulation with several AAC and AAC-HE files. It compiles and links for iPod Video and LogikDax (lowmemory target). No test runs on targets o far.

What has been done:
- Replace malloc() with static buffers.
- Remove free().
- Set several defines (MAX_CHANNELS, MAX_SYNTAX_ELEMENTS) to reasonable values to limit the memory consumption

What needs to be done:
- Cleanup (I think one or two arrays might not be needed anymore).
- Test and maybe some performance tweaking on targets

In the forums it was reported that gapless playback does not work reliably in svn. Working files could be produced with lame 3.96, older files created with lame 3.90 do not work (see: http://forums.rockbox.org/index.php/topic,27736.0.html).

The gapless information is read during parsing the Xing header. The code had an error in this section as it did not mask the upper 4 bits during a read operation (see the patch below). Therefor gapless did only work with files which had those upper 4 bits set to 0 (= enc_delay was divisible by 16).

A bug report in the forums states that resuming does not work as intended when resuming to the last seconds of a track. Details can be found here: http://forums.rockbox.org/index.php/topic,27655.0.html

Description by poster: “What you need is at least two successive tracks in a playlist, we’ll call them track1 and track2, with playtime(track2) > playtime(track1) (preferably at least a 10..20% difference). Then stop playback within about the last 2 or 3 seconds of track1, e.g. by a short press of the Power button (you don’t even need to power down). Hit the Home button and resume playback. You should find that you are well into track2 now.[…]”

Analysis: As assumed the resume issue occurs if you pause playback during a small time window. This window begins when audio_check_new_track() is called and ends when the new track is starting to play. Reason for the issue is that audio_check_new_track() calls playlist_next() which instantly increases the playlist index. The playlist index itself is used to save the resume position. Result: Rockbox will resume the previewed (next) track at the time position of the correct track. The time window has a duration 3 seconds (1 second for low memory targets). This is set in get_next_required_pcmbuf_size().[…]

The attached patch describes a possible solution. It uses mp3entry’s “index” to set the resume position. This “index” is set after the playback of the new track has started.

A forum post (http://forums.rockbox.org/index.php/topic,27409.0.html) made me check the code and the manual for the settings “List Acceleration Start Delay” and “List Acceleration Speed”.

1) There is no manual entry for those settings.
2) The unit for “List Acceleration Start Delay” was UNIT_MS, correct is UNIT_SEC.
3) The implementation used HZ/2 instead of HZ for the delays.
4) The implementation did not double the scroll speed each step.
5) The recognition of a repeated key in action.c uses a too short window (HZ/10). The recognition works more reliable in my tests with HZ/4.

Like described in the forums there is a high pitch noise added when decoding AAC HE / AAC SBR files. Please see http://forums.rockbox.org/index.php/topic,27465.0.html for more details.

This patch reworks the handling of the replaygain metadata. The goal is to save space in id3v2buf and to save some binsize. The svn implementation uses two independent representations for gain values: (1) an integer value which can directly be used by our dsp-code and (2) a string representation. The string representation is only used by WPS/screen for display purposes. To keep the string representation id3v2buf is used (9 bytes per gain).

Main idea of this patch is to fully remove the string representation and perform a snprintf() based on the integer representation when needing it for WPS/screen purposes.

In consequence the integer representation cannot be saved in a ready-to-use format for the dsp-code. When handing over the gain to the dsp-code convert_gain() must be called. Through dropping the string handling the replaygain related code became smaller (~300 bytes for a nano 2g).

As a bonus a svn bug is fixed that displayed wrong replaygains when parse_replaygain_int() was used to set the gains (used by mpc and ID3v2.4 tags).

With r29174 I have submitted a limit for the size of each metadata item. This is helpful to avoid that few items (like excessive comments) eat up the fixed size metadata buffer. This is especially important on LOW_MEM targets.
r29174 implemented this limitation for id3 tags only. This patch adds the same limitation to mp4 and other tags as well. Please verify this patch against your files.

Of special interest is handling of replaygain data in mp4 files. Can anyone attach or link one or two mp4 sample files with replaygain data?

The ID3 metadata parser does not correctly handle parse_replaygain(). The last parameter of parse_replaygain() is the buffer size which is left to save the string representation of replaygain. The current svn implementation calls parse_replaygain() with the length of the string to be evaluated by parse_replaygain().
Possible error case: It may happen that the left buffer is smaller than needed for the string representation.

I am providing this fix as a patch to have some reviewers and testers before submitting it.

Edit: Fixed some types in the comments.

The simulator does not compile under cygwin. Tested with sim for nano2g. These are the compile errors:

/cygdrive/c/development/rockbox_test/firmware/thread.c:197:2: #error Processor not implemented.
/cygdrive/c/development/rockbox_test/firmware/thread.c: In function `switch_thread’:
/cygdrive/c/development/rockbox_test/firmware/thread.c:160: sorry, unimplemented: inlining failed in call to ‘store_cont
ext’: function body not available
/cygdrive/c/development/rockbox_test/firmware/thread.c:1165: sorry, unimplemented: called from here
/cygdrive/c/development/rockbox_test/firmware/thread.c:136: sorry, unimplemented: inlining failed in call to ‘core_sleep
‘: function body not available
/cygdrive/c/development/rockbox_test/firmware/thread.c:1213: sorry, unimplemented: called from here
/cygdrive/c/development/rockbox_test/firmware/thread.c:163: sorry, unimplemented: inlining failed in call to ‘load_conte
xt’: function body not available
/cygdrive/c/development/rockbox_test/firmware/thread.c:1278: sorry, unimplemented: called from here
/cygdrive/c/development/rockbox_test/firmware/thread.c: In function `create_thread’:
/cygdrive/c/development/rockbox_test/firmware/thread.c:1620: warning: implicit declaration of function `THREAD_STARTUP_I
NIT’ /cygdrive/c/development/rockbox_test/firmware/thread.c:1620: error: `core’ undeclared (first use in this function)
/cygdrive/c/development/rockbox_test/firmware/thread.c:1620: error: (Each undeclared identifier is reported only once
/cygdrive/c/development/rockbox_test/firmware/thread.c:1620: error: for each function it appears in.)
/cygdrive/c/development/rockbox_test/firmware/thread.c: At top level:
/cygdrive/c/development/rockbox_test/firmware/thread.c:136: warning: ‘core_sleep’ declared `static’ but never defined
/cygdrive/c/development/rockbox_test/firmware/thread.c:160: warning: ‘store_context’ declared `static’ but never defined

/cygdrive/c/development/rockbox_test/firmware/thread.c:163: warning: ‘load_context’ declared `static’ but never defined
make: *** [/cygdrive/c/development/rockbox_test/build-pcsim-nano2g/firmware/thread.o] Error 1

Unify variants within talk_time_unit(). In svn there are two variants which are triggered via UNIT_TIME_EXACT or UNIT_TIME.

Example:
“02:45 h” ⇒ “2 hours 45” when using UNIT_TIME
“02:45 h” ⇒ “2 hours 45 minutes” when using UNIT_TIME_EXACT

After the latest changes UNIT_TIME is only used in one single place. Additionally it was agreed in IRC that the precise form might be better to use for all languages. This patch removes the variant and will always use the precise form.

Rockbox’ ID3 parser does not trim strings fields with in-lying null-termination or multiple zeroes at the string field end. For ape, aac and ogg this is already done.

This patch adds trimming to the ID3 parser in a very simple way. The next item is allowed to be written beyond the next following null in the array. Savings are few, but could be interesting for our reduced metadata size on low memory targets.

I find it useful to have more detailed information of the current codec / format available. For example svn does not differ between AAC and AAC-HE or MPC SV7 and MPC SV8. The attached patch introduces two new types AFMT_MP4_AAC_HE and AFMT_MPC_SV8 (AFMT_MPC is replaced with AFMT_MPC_SV7). The detection of those types is added to the dedicated metadata parser.

Additionally those new types need to be handled in the helper function get_codec_base_type() to avoid uneccessary codec re-loads. When I added those new types to this function I found that the recently added ATARI formats needed to be added as well.

In the WPS formats are now displayed as follows:
Musepack SV7 → “MPCv7” Musepack SV8 → “MPCv8” AAC → “AAC” AAC High Efficiency → “AAC-HE”

As reported in http://forums.rockbox.org/index.php/topic,27098.0.html there were issues with the nano 2g LCD reported (see Forum thread or attachment for a photo).

The following information has been collected so far:

revisions

working → r25375-100328
non-working → current (something after the latest speed optimizations)

LCD type

From diagmode it shows:
LCD Detect0:1
LCD Detect1:0

Also in hardware debug:
LCD:
type: 1, (7) LDS176

Extracted from  FS#11830 . Since the issues described below also occur when  FS#11830  is not applied this bug report is generated.

On iPod nano 1G and iPod Video’s the following were issues observed:
1) Device does not fully start (no menu visible, background image loaded)
2) Playback stopps or does not start (WPS playtime is 0:00)
3) “data abort” on white screen

Except (1) and (3) the iPod’s UI responds. In situation (2) loading mpegplayer or shut down via longpress Play/Pause is not possible. In general plugins (tested with test_fps and test_mem) can be loaded and performed normally.

On iPod Video this happened with builds which based on r28915, r28940 and r28960. So, before the ATA but after some kernel/thread/priority changes.

I could provoke this failure twice when generating the DB during playback. But these failure also happened randomly during standard playback (mp3 and mpc in my case).

As long as we do not know what is happening I will assume this is not specific for PP502x processors.

USB is broken for iPod Video. Tested with r28971 and r28953. An old local build based on r28407 works fine.

What happens: When you connect USB rockbox switches to the USB screen, but does not show up under XP. When you disconnect USB the USB screen goes away and the device is usable.

The files cook_mono_64.ra, cook_stereo_64.ra (from http://download.rockbox.org/test_files/) and FUN_RM_132.rm (from http://samples.mplayerhq.hu/real/AC-atrc/) do not play anymore. This is with r28960.

This task provides changes to the iPod color/nano1G LCD driver that affect both RGB and YUV screen updates. For the YUV optimization the asm from the HDD6330 is used, for RGB a special case handling for (width==LCD_WIDTH) is introduced.

v01 = only affects YUV
v02 = YUV and RGB changes

This patch implements some changes to the iPod nano 2G LCD driver.

1) Do not poll FIFO full state, but for FIFO half full state. FIFO size is 16 bytes. So, when FIFO is not half full it is possible to write up 8 bytes (= 4 pixels) at once. This reduces the number of polls by far.
2) Force “width” to even in lcd_update_rect() to allow writing 2 pixels per loop.
3) Write 4 pixels per loop when (width==LCD_WIDTH).

Speed up is ~50% for RGB and 25% for YUV.

Edit: My nano has a LDS176 type LCD.

This patch does two things
a) Raising the boosted clock to the max allowed (CPU = 200.7 MHz, HCLK = CPU/2, PCLK = HCLK/4). The unboosted clock is using 200.7/4 for CPU/HLCK/PCLK.
b) Using mainly two different DRAM settings (MIUSDPARA) for boosted and unboosted clock. Those were derived from the data sheets of S5L8700 CPU and the K4M56163PG DRAM. To ensure proper startup crt0.s uses the Apple FWs DRAM configuration.

The raised CPU clock allows +4% of maximum CPU speed. Additionally the changed DRAM settings will speed up DRAM write by 10% (boosted) or 40% (nboosted). The DRAM settings do not have any (or very minor) impact to the speed of DRAM read and IRAM access.

In current svn the CACHEALIGN macros are not defined except for PP CPUs. This patch enables those macros for all CPUs. For those who have CACHEALIGN_BITS defined, this value is used to calculate the alignment. For others a default alignment of 32 bytes is used.

The macros can e.g. now be used to optimized codec buffers. I have attached a patch for this as well.

align_v02.patch: Just use CACHEALIGN_BITS like defined for the CPUs in svn.

align_v03.patch: Additionally define CACHEALIGN_BITS for as3525v2/tcc78/tcc77-CPUs (5) and mcf5249/mcf5250 (4)

align_codecs_v01.patch: Replaces the hardcodec alignments with the appropriate macros.

Speed-up on S5L870x (nano 2g) is ~4-5%. No impact on PP502x / PP5002.

Should be measured on other CPUs as well.

This patch enables the “line out on/off” feature for the iPod’s 4G, Color and nano 1G. This can easily be activated as the WM codec is the same as for the iPod nano 2G – which already has this feature. Nevertheless I am not 100% sure the headphone/lineouts are wired the same.

What is needed to be tested: Does this feature work as expected on the different iPod types (4G, Color, nano 1G)? If possible please also report the savings in battery current when switching off the line out during playback.

The following patch reduces the voltage of the nano 2G LCD controller’s power supply. Voltage is lowered from 3.0 V to 2.6 V – 2.6 V is the minimum common voltage for both ILI9320 and LDS176 types.

With this patch my nano 2G (LDS176) stops humming :o)

This patch needs verification with a ILI9320 LCD type.

With r28016 my PCSim does not show any subpaths in the simdisk folder. The PCSim has been built for iPod Video under cygwin. “Show files” is set to “Supported”. When setting “Show files” to “All” the file browser shows all subpaths, but I cannot enter them.

I only have an old build left based on r25259. This build shows all subpaths and allows to enter them – with “Show files” set to “Supported”. I used an updated PCSim when working on my latest submits regarding buffering. Therefor the file browser worked with revisions ~r27950.

In the forums there is an issue described when trying to play certain m4a-files (see http://forums.rockbox.org/index.php?topic=25602.15 or  FS#11539 ) which need a seek after the m4a-parsing. Those files are parsed at the fileend and afterwards need to be seeked back to the beginning for playback.

The attached patch hotfixes the issue, but does not seem to be the best and final solution. Tested on iPod 5.5G and Sansa e200.