The attached patch implements sinc based resampling in rockbox.
I have only tested it stand-alone so far (i.e. the code outside of rockbox – I am waiting for a replacement for my broken android phone to test it there).
There is (of course) quite some room for improvement.
Things which could be improved:
- buffer handling
- calculate the correct sinc spanning the whole table for downsampling. Then the downsampling and upsampling code would be the same (no need for sinc_increment, saving some additions). Also the result would be more accurate resampling.
- Save some memory by always calculating the correct sinc and putting it into resample_data. Would need to use fp_sincos() for that.
- Save some more memory by taking advantage of sinc's symmetry, only storing half of it in the table.

I know that I'm breaking the coding-style by using more than 80 chars in some lines. I will fix that when I have time. I wanted to get this code finally out to get some feedback after it sitting for two weeks (basically unchanged) on my HD.

- write a word like “مسمار” in a text file, or just use the word as the file name

- the last character “ر” will appear as the first one like this: “رمسما”

- this bug appeared only since r26019

- when reverting to r26018 the bug won’t show up

- for some combination of letters like “دليل” the issue happens for the last 2 characters

- for some other words the problem doesn’t happen at all

- the only common case is that this happens only with last word in a line appearing on the viewport

This patch puts the pacbox emulator onto the cop, leaving the main cpu for audio codec. The COP behaviour is controller by a #define in pacbox.h

If PACBOX_ON_COP is defined, then all iram usage is also turned off, to prevent interference with audio thread.

Additionally, this patch adds an Audio menu (using the playback_control library), which is enabled for all PACBOX_ON_COP and GIGABEAT F-Series builds.

Patch from directly within the apps/plugins/pacbox directory.

The scrollpad on the H10 (20gb, not sure about 5/10gb) has always bothered me with being jumpy, inaccurate, and unintuitive. At the moment (in rockbox) it seems as though it is working as a simple two button device (up/down), with no real dragging capabilities. I am wondering if this is a limitation of the hardware or current software implementation.

The original firmware seemed to work as follows:
split slider into upper and lower field. Tapping in either upper or lower half would create click-type event for up/down. Dragging in upper half would produce scroll up, draggin in lower half would produce scroll down events. The problem was that upper and lower halves are really kinda arbitrary and not easily distinguishable.

What I think would work nicely:
Tapping top and bottom, as before. Remove upper and lower restrictions for dragging, i.e. if dragging down (anywhere on the scrollpad) create scroll down event, if dragging up (again, anywhere) create scroll up event. Drag and hold will scroll in desired direction proportional to the drag speed (as in pushing a puck on ice). Hold (just hold, no tap or drag) on the touchpad creates a sliding value that can be used as a coordinate for different types of continuous input.

To implement this, we’d need some kind of knowledge about what signals the actual hardware provides, what resolution the pad has, i.e. what the physical and logical implementations of the device are. I am not sure how the Ipod scrollwheel works, but it seems that some of that code could be re-purposed, maybe?

This should hopefully make beatbox compile and run on any target with enough buttons.

All it needed was some key mappings (and some typo fixes). I’m assuming the function declaration for synthSamaples() simply changed over time, as the original code was missing an ‘s’ on the end of function name and looked like this:

  synthSamples(&synthtemp[0], &synthtemp[1]);

The second param should be the sample size or something, but it was passed an address.

If it doesn’t work on a particular target due to lack of a key map, please add one, or tell me the target and i’ll stick a keymap in

Patch from within root rockbox source folder.

Hopefully this works for you all, its many hours of fun =D

The OF ide_power_enable routine sets some GPIO _ENABLE bits to zero when enabling power and sets them to 1 when disabling power. This makes a difference of about 1 in 4066_ISTAT ( FS#9728 ) on my 30 gig iPod, which probably means saving about 0.75 mA. But if 1 is enable, why does enabling pins save power?

this patch is a WIP to update the bookmark system.

the change is to save “resume points” into the current .playlist_control file and copy that as a .bmark file. Right now it works fine to load and save (And even list the bookmark resume points).

What doesn’t work yet (in bmark.3.diff) is the recent bookmarks menu item.

So far, the only downside I have found is that when you open a .bmark file the current playlist has to be stopped (it gets bookmarked automatically so if you cancel the .bmark it will resume anyway).
I’m hopeing that this isnt a big enough issue to reject the patch.

It’s still a bit rough around the edges, but I’ve written a new game plugin called NBackBox. It’s an implementation of the dual-n-back exercise, discussed in this Wired article: http://www.wired.com/science/discoveries/news/2008/04/smart_software . In short, it’s a game that improves your brain’s working memory. I’ve tried to keep it as close to how the game was described in the original paper.

Any feedback/bug reports/code suggestions much appreciated :)

Joe

This patch is inspired by FS7571.

Currently we can move to next/prev directory with <short left/right + long left/right>. This patch changes two part of this functionality:

1. If <Auto-Change Directory> is not enabled, move to first track of current/next directory only within the playlist.
So you can maintain dynamic playlist. This was very annoying problem for me.

2. do not wait till <long left/right> is released.

So ffwd or rewind will not be performed at new track.

Hi, this is a new codec based on the SC68 library
by Benjamin Gerard (sc68.atari.org).

Revision: 29484
Tested on: Sansa Fuze v2

Features:

1. 44 Khz Stereo sound.
2. Supports sc68 and sndh files.
3. Support for multi track and single track files.
4. Metadata parsing.
5. Fade out support.

** This codec needs the sc68 Replay folder to work, just put it in the root of
your player. you can find one here: http://aminet.net/package.php?package=mus/play/sc68.lha

Notes:

1.  This is a beta codec, some (big) songs may cause rockbox to crash.
2.  When compiling the sc68 library i had a lot of dependencies errors with
     missing includes.  It is compiling fine now on the vmware image, but not in cygwin.
     I still have to find the problem with that.
3.  Some songs doesn't work, specially some big sndh files.  I'm still working on it.
4.  Seek support is broken, i'm working on it.

Please feel free to make any comment or suggestion.

build 00a3658. files dont list or play alphabetically regardless of setting in file view menu.

Adds “Binary Skip” to the skip length menu,

This allows navigation by means of binary search within a track.

If no search key is pressed for 5 seconds, the current binary search is considered as having “finished” and pressing a search key subsequently initiates a new binary search.

For a couple of months my Sansa Fuze v2 has been crashing randomly when playing music. Most of the time I just get a white screen with an error message. The last message I got was :

'undefined instruction at 0006DC8C'

(I think that last number varies at each crash)

This didn't happen with v3.13, but it's been happening with every daily build I've tested IIRC.

It doesn't happen very often so it's hard to reproduce. I listen to music in public transports about twice a day and this happens not more than once a week. It seems to happen more often when the battery is low (less than 10%). It generally happens early in a playback session, when the first or second track is played.

Sometimes I don't get a white screen, but the program freezes and some parts of the interface are surrounded with white frames. I don't know if it's the same bug or if it's unrelated.

Note that I'm always listening to music on a microSD card, and I haven't tried on the main memory.

PS: I chose "Sansa Fuze+" in the OS list because I couldn't find Sansa Fuse v2.

While in the fm radio screen, a ticking noise can be heard in the background. When pressing the power button in the radio screen the noise disappears.

As discussed on the mailing list this patch gets rid of the “About to Erase Dynamic Playlist” warning and replaces it with a menu option to save the current playlist under it’s existing name.

The attached patch is a first cut for review as I’m just getting used to the menu system. If people think it’s the right way to go I’ll clean it up properly. Any suggestions for tweaks to the functionality also welcome.

I have been using Rockbox for almost 2 years now on my X5L together with the remote and I have frequently updated to the current version, so I am familiar with how it works.

I have noticed that after updating to version 20090221, my X5’s remote’s LCD behaves erratically (strange lines being displayed all over, vertically shaky image) right after booting Rockbox, then the display turns off completely after a few seconds. Strangely though, the controls still work and the blue display light comes on when working the controls, but the display is turned off (there is nothing being displayed, as if the player were turned off). If I unplug and reconnect the remote, the remote’s LCD comes on, but soon turns off again. The X5’s main LCD is working just fine.

I thought that my remote was dying on me, but decided to check if it was somehow related to the development of Rockbox. I reverted back one build after another and found that the last build that works OK for my remote is 20090210. So, in all the builds starting with 20090211 (I have thoroughly checked all from 20090211 to 20090225), the remote is practically unusable. I looked at the changes done on that day (http://www.rockbox.org/daily/changelogs/changes-20090211.html), but could not single out the probable cause.

Great software, anyway!

This very small mod changes the tracklist so it doesn't fade lines when on a mono display (bit depth 1). Tested against r26241 in Sim only (because I don't have a mono display device).
Please report back if problems.

Sometimes when I shut my unit off and then turn it on again and resume playback, RB resumes from a different place than where it left off, and even though when I resume shuffle is on (as indicated by its icon), it isn’t. It’ll play the current track, then the next track in the playlist (which in my case is in order by track number, so it’ll play the next track on the album), and so on.

If I turn shuffle off and then on again, shuffle works correctly again.

I’m using a build from January 19 (19800-090119) on an Archos Recorder. I
noticed this bug occurring in the 3.1 build as well.

It seems to happen randomly – I can’t figure out anything specifically that I can do to always make it happen.

this patch adds a setting to choose what to do on a usb connection. default is to connect. options are charge only or connect..

holding *any* button will swap the outcome…

it works, but not perfectly… and the manual patch needs to be checked

By default, whenever you choose the <All Tracks> option from the database menu, the list of results returned defaults to the standard track name format, i.e. “%02d. %s” tracknum title. What I wanted was to be able to define the format that gets applied to the <All Tracks> option, dependent on the current menu level. So for example, if I had browsed to genre→artist→<All Tracks> it would return the list of all tracks for all artists for the given genre and I wanted the track names to be formated with:

       	"%s %s %02d. %s" artist album tracknum title

and then sorted into order, since I already know what genre the tracks are for.

Similarly, if I simply browsed to genre→artist→album→<All Tracks>, it would return the list of all tracks for the selected genre and artist, but I want the track names to be formated with:

"%s %02d. %s" album tracknum title

so when it’s sorted, I get the tracks grouped only by album and tracknumber, since I already know what artist the tracks are for.

This patch attempts to address this issue by allowing users to define custom <All Tracks> formats in the tagnavi_custom.config file. Thus, sort order can be controlled by how you format the track names, just as it works in base Rockbox.

The premise behind the code is that if the <All Tracks> menu option is chosen, Rockbox will look for formats with a certain naming convention defined by concatenating the tag names of the parent menu levels with “.” characters and finally appending an “.All” identifier. So in the first example above where we had browsed to genre→artist→<All Tracks>, Rockbox will look for all formats called:

"genre.artist.All"

and then cycle through them to see if the appropriate clauses defined on the format are met. Similarly, for the second example where we had browsed to genre→artist→album→<All Tracks>, Rockbox will look for the format called:

"genre.artist.album.All"

As in base Rockbox, it will cycle through all applicable formats and apply the first format it comes across that meets all the clauses defined on the format. One minor change I had to make to get the relevant tags loaded for the search results was to add the tags defined in the clauses of all matching format names to the tagcache search, but not add the clauses themselves.

So now, in the tagnavi_custom.config file to illustrate the first example, I have defined 4 formats called “genre.artist.All” to format the final display name based on whether the artist/album tags are actually defined on the mp3’s in the database.

%format “genre.artist.All” “%s - %s - %02d. %s” artist album tracknum title ? artist !~ “<Untagged>” album !~ “<Untagged>” tracknum > “0” %format “genre.artist.All” “%s - %02d. %s” album tracknum title ? album !~ “<Untagged>” tracknum > “0” %format “genre.artist.All” “%s - %02d. %s” artist tracknum title ? artist !~ “<Untagged>” tracknum > “0” %format “genre.artist.All” “%02d. %s” tracknum title ? tracknum > “0”

The downside of this approach is that in order to have this style of functionality for every <All Tracks> menu option, I defined a lot of formats. As such, I had to increase the maximum number of formats from 32 to 96 in order to cope with my formatting schemes. I also increased the maximum number of tag filters from 4 to 8. Now this obviously increases the amount of memory allocated for formats, which will have an impact on available audio buffer size. The attached tagnavi_custom.config file shows the various “All” formats I’ve added and it’s pretty comprehensive in the way it handles missing tags, so technically, if your music library is properly tagged, you should never need all of the formats so you could easily reduce the maximum number of formats.

My principal concern with this patch is in terms of the memory usage of increasing the maximum number of formats and number of tag filters allowed. I’m not aware of a memory profiler for cygwin, but then I hadn’t used cygwin before playing with Rockbox - so any pointers would be helpful.

The second piece of functionality I wanted was in the handling of the “strip” functionality. Base Rockbox has an all or nothing approach; if the global format found for the list of tracks contains a strip modifier, then it applies the strip to ALL track names, even if the subsequent formatting of the track does not contain a strip modifier. I wanted Rockbox to only strip tracknames if a strip modifier was defined on the format that is applied to the track. This patch fixes this problem.

This works fine on my Sansa e280 with a full 8Gb drive and a full 2Gb micro-SD card. It’s formatted close to 1000 tracks with no noticeable difference in processing time, and I’ve not come across any out of memory errors on my e280, but I haven’t tested it on any other mp3 player so I would recommend you test this first using the appropriate simulator.

Note that this patch incorporates the year album patch  FS#8051  as the code is all tied up in the same files.

This patch introduces 2 new activities, one which lists available themes for a specified target and another which lists more details and the option to install the specific theme. Currently this is more a proof-of-concept, as the communication with the theme server is handled by the same API RBUtil uses, which isn't perfect for the intended usage (e.g. offers no possibility to filter by screen size, only uses INI as output format, ..).

(this also includes some minor unrelated changes to the main Rockbox extraction functionality which won't be in the final patch)

TODO:
- make translatable
- better UI
- uninstall/update functionality
- show only themes fit for the displays' resolution
- use different protocol to communicate with theme server to get rid of iniparser dependency (XML, JSON, .. ?)

I've found a problem with the new autoresume feature in 3.8. I use it when listening to podcasts and sometimes find that it resumes from near the end of a new episode - e.g. on a 30 minute podcast it will resume from 28 or 29 minutes - usually about the place where a previous epidsode finished and I skipped past the end credits.

What I think is happening is that there is some code in the database that tries to resurrect the runtime statistics for files that have been deleted and then restored - as the last offset is in this data, it is reusing the last offset from an old episode.

I've put some more logf()s in tagcache.c in build_numeric_indices(). I can see that if the filenames don't match (line 2306) it then tries to match any 2 tags out of the 3: artist, album or title. For the podcasts, the artist and album are always the same (i.e. the producer and which one of their podcasts it is), but the title is different (i.e. "Episode 100", "Episode 101", etc). So if I've listened to Episode 100 and then deleted the file, and then add Episode 102 to the player, it matches the artist and album and so resurrects the wrong data from Episode 100.

I've disabled the resurrection based on tags (just commented it out) and the problem seems to have gone away. A better fix would be to ensure that all 3 tags or matched or to ensure that title is one of the matched tags

Steps to reproduce:

1. Start listening to a series of podcasts, say 1-5
2. After listening to >1 plug player into computer during playback of subsequent podcast
3. Delete the podcasts you have already listened to (not what your currently listening to)
4. Eject/Unplug player from computer
5. Attempt to resume playback

This fails for both resume and Recent Bookmarks functionality. I assume this is somehow tied in with playlist support as files from the playlist have been deleted.

Where does Recent Bookmarks keep it's information? Should the bookmark also keep the individual file referenced so it can resume in this case?

Tested on R21184M-090604

Will test on latest version once my main machine is back on internet.

This patch is a proof-of-concept for an adaptive runtime estimation.

Reason to implement such behaviour is that different user settings and user behaviour have large impact to the power consumption and – as a result – to the runtime. E.g. disabling LCD will save lots of power, but some users do not want to disable the LCD to keep readability in daylight.
This patch therefor adapts the estimation of runcurrent() based upon real measurements of the current consumption. The algorithm starts with a default (CURRENT_NORMAL which is defined in the config-file of each player) and uses a weighting scheme with a large time constant to adapt the estimation of the current consumption. The time constant is 1024, which should equal ~20 minutes as the runcurrent()-function is called once per second. With a smaller time constant the runtime estimation is “pumping” too much when the HDD is active.

This first version is just a hard coded experimental solution. Nevertheless something like an actual_current()-function can be implemented for each player in its own powermgmt-file. Players with capability to read the current will return this measured real current, all others still return the fixed default CURRENT_NORMAL.

External/USB adapters are not correctly detected on my Classic 80Gb, this patch detects it so car mode functionality now works, also the iPod is powered-up when USB cable is inserted.

The function power_input_status() returns USB charger when both external and USB chargers are present. It is possible to detect the external adapter when USB cable is plugged but it is necesary to poll the PMU (not IRQ safe), and i think this information is not currently used at all.

I used the official toshiba updater to get an “original” fresh install on my beast and then attempted to run through the install procedure for a single boot rockbox install. After a (seemingly) sucessful install I’d end up in recover mode after any reboot.

Fatal error when attempting to install nk.bin (rockbox only bootloader) using sendfirm in Windows to an updated (v1.2) Gigabeat S player.

After install of both bootloader and rockbox the Gigabeat S, once rebooted, goes into recovery mode (toshiba) and requires an update/restore. This is the Number 3 Triangle.

Notes:
Gigabeat was first updated using the official toshiba MESV12US updater. “gbs_update_1_2_us.exe”

Using SVN revision 19741 to compile nk.bin under WinXP and Cygwin.
Using MTP.zip of 7/4/2008 found on the wiki to send over the bootloader.

I suspect most devs updated their bootloaders using the sendfirm utility *before/without* updating the entire player with the updater utility from toshiba. Thus they started from a v1.1 OF and never updated any part of that.

Maybe the updater changes something in the bootcode. I don’t know.

I downloaded some AAC files from the bbc, using the get-iplayer utility. The files play just fine on the computer, but on my rockboxed Clip+, they seem to freeze up the player entirely. I have to hold the power button for a long time to reset it. I just tried updating to rockbox 3.9, but I'm not seeing any difference with the new firmware.

When I play the file in mplayer, it gives the following info:
major_brand: M4A
minor_version: 512
compatible_brands: isomiso2
encoder: Lavf52.64.2
========================================================================Opening audio decoder: [faad] AAC (MPEG2/4 Advanced Audio Coding)
AUDIO: 44100 Hz, 2 ch, s16le, 48.0 kbit/3.40% (ratio: 6000→176400)
Selected audio codec: [faad] afm: faad (FAAD AAC (MPEG-2/MPEG-4 Audio))

I’ve noticed that many plugins don’t have the Playback Control menu even though they could. I’m going to have a go at fixing that.

I’ve categorised the plugins which could use the menu like so:

Already have a standard-ish menu (not bitmap), it just needs to be added:
bubbles
chessbox
chopper
minesweeper
reversi
superdom
wormlet
xobox
clock
fireworks
vu_meter

These are the easiest case, it’s just a matter of adding the menu item.

Don’t have a menu that makes sense to add Playback Control to (either they don’t have a menu at all, or they only have a start-menu that can’t be usefully returned to):
flipit
invadrox
maze
robotfindskitten
rockblox
rockblox1d
rocklife
sliding_puzzle
snake
snake2
spacerocks
star
stopwatch
mandelbrot
oscilloscope

These are a mixed bunch. Some could actually use a menu, and some could just have a key assigned to bring up the Playback Control menu. More involved than the first bunch in general.

Already have a menu, but it’s really custom in some way. They either need to be switched to more standard menus, or something special needs to be done:
brickmania
chessclock
pegbox
rockpaint

These will probably be the most work.

Let me know if I forgot any plugins, or if you think it doesn’t make sense to add the menu to a plugin that I’ve listed above.

Attached is a patch for the first bunch. The others will be coming eventually.

I’d appreciate it if you leave this FS entry open until I get to the second and third bunch, even if the first bunch happens to get commited to svn.

This is a plugin that locks your player with a 4-digit code. The default code is "0000", until you change it.

Sansa Clip Zip has big problems with Lossless files. BIG.

1) Flacs skips randomly, at every encoding level (5 or 8 it's the same) and it's impossible to reproduce this issue when I want. It skips to the next track randomly
2) Ape files stops to reproducing and makes a really big noise, this after 30 sec. or 3 min… or nothing at all.
3) Wavpack files, sometimes, stucks for 0.5 seconds and then, it continues to play. It happens to Fast encoding, or Normal encoding, it's the same.
4) AAC files make little noises and, sometimes, crash Rockbox.

Flac and APE problems, I'm sure, occurs from ages, I bought Clip Zip months ago and these problem occurred for every build and ofr every Rockbox release.

I don't think that my player's broken. These problems were previously posted by other people.

I think that the testing of builds were made too hastily, there are too many problems with lossless files. I can understand APE that requires an expensive decoding, but FLAC files couldn't have these problems :(

I am reopening  FS#11501  - Sansa Clip v2 FLAC playback skips regularly, which was closed because a sample file was not provided. I didn't think this was necessary because I stated it happened regularly with just about any file.

I am currently on build 30217. It skipped for me last night on this track:
http://www.archive.org/download/johnbutlertrio2011-07-24.lsdII.flac16/johnbutlertrio2011-07-24_lsdII_t07.flac

I cannot attach the track to this ticket because it is larger than 2mb.

Again, it is nothing inherent in that track: a second playthrough did not skip. That 16-bit/44.1khz track was generated with FLAC 1.2.1b using normal procedures.

This problem has occurred for any build I've ever tried on a clip v2 player.

Here is my original problem statement:

Build 27566 (and all previous builds), Sansa Clip v2.

playback of 16-bit/44khz FLAC format regularly will skip ahead to next track.

in a 60 minute playback session, it'll probably happen 2-3 times. this is not due to a defect in the FLAC files. it happens with any FLAC set I attempt.

this does not happen with the Clip v1 on the same build number.

this is my first bug submitted. I searched for duplicate reports but didn't find anything.

thank you!

Hi,

I think that the problem reported on  FS#10919  is still here, or at least not completely solved.
But now, I get the feeling that the pause only happens when the buffer refill is triggered via a track skip. During normal playback, it don't seem to happen any more.

The build I tried it on is r25249.

TIA

Been using Rockbox for years, so it was really obvious when things got messed up somewhere in 3.12~3.13. In a nutshell, with this release, in a 1000+ playlist, I’m listening to the same songs over and over again when shuffle is on. To fix the issue, I have to turn shuffle OFF and then flip it back to ON every time I start a player. Never had this problem before. Don’t know if this affects all devices or just my H340 (yes! still going strong!).

This flyspray task will hold the development of a potential usb audio driver for rockbox.
It will also serve for the development of the isochronous transfer support support in usb code.

Adds runtime calibrated from (numerous) battery_bench runs on ipod 5g 64mb (60gb)

This patch adds a rotate option to the jpeg viewer.
Tested on sansa e200. Works on colour targets only.
Additional work required for zoom and moving around the pict.

GRaTT

Some collections (such as ftp://sunsite.unc.edu/pub/Linux/games/amusements/life/dblifelib-2.tgz) use an extension of “.l” instead of “.cells” for what appears to be the same file format (same comment character and same characters for dead and live cell).

This patch just adds an entry to viewers.config so that Rockbox will treat .l files as supported and open them with Rocklife.

Version: r28861
Used before: r26706

Hello,

with r28861the touchscreen works with glitches.
When I touch a line-item , the system sometimes don't react or the line selector just "twinkle".

My conjecture:
It has somethin to do with the new "kinetic-scroll"-feature, because after a little kinetic-scroll the touch become precise.

(And yes, I've done a calibration: no effect)

Work in progress patch. Currently decodes audio but with some glitches. Has a small mountain of debug code included.

The basic idea is to rearrange the D filter coefficients in the synthesis filter so that pairs of them are used sequentially. This is not easy because the taps need to be loaded in the seemingly random order needed by the audio samples. However, this rearrangement seems to be possible:

0 1 2 3 4 5 6 7 (original sequence)
0 2 1 3 4 6 5 7 (new sequence)

The complication is that the code assumes that it can start a new filter at any offset, even odd ones, which means each and every filter needs to be rewritten 4 times, one for each of the 4 possible alignments. This patch does that.

Once I'm certain that it works, I intend to convert the D coefficients to packed 16 bit values, then use packed 16 bit multiply instructions on ARMv5E+. This should lead to a small speed up on armv4 (just because ldm instructions can be used instead of ldr) and a very large speed up on arm9E and arm11 (because packed multiplies are tremendously faster and much easier to pipeline).

If playback finished with repeat off, let you resume the last playlist by pressing play or selecting the 'resume playlist' option in the main menu instead of showing the dreaded "nothing to resume" splash.
As a side effect it will also resume if you restart the player and have it set to resume which you would probably want to fix. I didn't update to the latest revision (i have 21295) that has jdgordon's namechange thing so it will probably show 'nothing to resume' if you apply it but still actually resume.

The attached patch adds an indication of the current touchscreen mode to the "classic_statusbar" skin. This is useful since some screens automatically change mode, and there's currently no indication the user when this happens. The patch does the following:

- Adds a new WPS tag (%Tm) to return the current touch mode (Absolute|Grid)
- Updates classic_statusbar.sbs to conditionally show the correct icon

The reason I've made this a Flyspray task rather than just committing it is because the additions to classic_statusbar.sbs will also apply to non-touchscreen targets (though nothing will appear on screen). While the impact on these targets is minimal, I'm not sure about committing it since it will at least cause the new touchmode.bmp to be loaded unneccesarily.

Also, feel free to design some better icons!

rockout is a sampler that can play 6 samples at a time (unlimited playback length). sample playback is 16 bit 44.1khz. you can play samples back, you can glitch samples out using the glitch sequencer, there is echo, there is distortion, backwards, and a record loop function. you can load your own samples into rockout (stereo .WAV 16bit 44.1khz files)

rockout currently works on the sansa e200 series and c200 series. don't hold your breath for other players to work, due to their greatly lower amounts of RAM.

—

rar file only includes 1 very small/crappy sample pack. more (better) sample packs available at:

1) the motherload: 10 folders of samples, almost all hand selected/cut by myself:
http://www.megaupload.com/?d=BXMTW9T8

2) individual folders:

https://docs.google.com/leaf?id=0BwiF_VSZhsHjNjY1OWQzZTQtY2M2Zi00M2NhLWJlN2EtOTI0Nzk2MTJiYjI5&hl=en_US

https://docs.google.com/leaf?id=0BwiF_VSZhsHjYjQwMGFmOTMtMjM4YS00YTZjLWJkNzUtZTEzOGEzMTU0YzI0&hl=en_US

https://docs.google.com/leaf?id=0BwiF_VSZhsHjNjE0ZTc3YTUtYTNiZS00ZGJjLThmNTQtNmQ1MWU0NTk3YjRj&hl=en_US

https://docs.google.com/leaf?id=0BwiF_VSZhsHjNjM4NzMxYzQtZTVkZC00OGZhLThiZDUtMjYyZTgzNzFmZWQ2&hl=en_US

https://docs.google.com/leaf?id=0BwiF_VSZhsHjMjFiNDk2ODQtZmU2YS00Yzk0LTg3YTMtNDY1YWMzYjU4ZmM0&hl=en_US

https://docs.google.com/leaf?id=0BwiF_VSZhsHjN2MxZWE0NTAtMmJmMS00YmZjLWFjM2YtMjM1NzlhOWUyMmMz&hl=en_US

m4a Songs skip in middle of playback, to next song.
always at same point. fast forwarding beyond this point is fine.
files work fine on other devices/PC.
reverted back to v3.6 and all such problems are gone

The iPod Classic Cirrus CS42L55 DAC+amp chip is specified to output audio up to +12dB versus the reference level (0.775V RMS) and the current Rockbox driver implements this accordingly (note that the OF limits the amplification to a lower level).

However, any amplification above +3dB applied to a 0dB signal results in serious clipping errors, the sound being distorted (oscilloscope measurements attached). This is not a surprise, given that +12dB translates in over 8V peak-to-peak output, way above what the iPod is capable of with its 3.7V battery.

Distortions aside, +12dB can be overkill for most of the earphones (depending on the sensitivity) and not a very pleasant experience. If you put the iPod in your pocket and forget to lock it you may experience this frequently.

In practice not all tracks have peaks reaching the 0dB level (actually nowadays this is quite common given the "loudness war"). To provide some room for additional amplification when needed, I found the +6dB limit to be a good compromise.

I don't know whenever it happens with other versions or not, all I got is Sansa Clipv1 to test with.
My configuration is Initialize once and auto update working.

It seems like the database items got duplicated for unknown reason. I seem to have up to 7 entry's of the same item inside the database. I am not sure what causes it, but that is what I've noticed.
[At first I thought it's a shuffle bug 'till I was going to debug it only to find the database is full of clones]

Delete current file from within the jpeg viewer plugin.
Adds delete to the options in the menu
Also highlights the last file viewed in the file browser on quit.
GRaTT

When utilizing the database on the iPod Photo (as well as other 4G iPods I have used), on occasion when entering a directory or going to the parent directory, any button on the iPod will need to be pressed before the others will have effect. I.E. before I can scroll to select a song, I must press Select or one of the other wheel buttons. It is severely annoying, in part because it is too sporadic to even be assumed to be a “feature”.

I know that the folks that added recording functions to the PP targets only did it as a proof-of-concept, which rteally works well already. I am curious if anyone has looked into the bizarre noise that is generated on the right channel, I have tested this on two different 4g grayscale ipods and on 5.5g ipod. The noise level is lower in the 5.5g than the 4g's. I have attatched a png of jamin running a "silent" recording (no mic connected) and the wavpack file. I amplified the sound to get it to register higher on my spectrum analyzer.

After releasing hold after several minutes of playback with hold enabled, the backlight flickers on and off, if the following settings are enabled:

Backlight on hold: off
Backlight fade in: on
Backlight fade out: on
Caption backlight: on

My theory is that fade-in/out events from the caption backlight somehow get queued up, and happen once hold is released.

Happened as recently as today, with r21438. Reports in IRC said it appeared somewhere between 3.0 and 3.1.

This patch provides a replacement for buffering.c, where there is only minimal buffering (one 32K buffer for audio data and some static buffers for metadata). It is a proof of concept for how this could work on targets with very little RAM.

I would be interested in feedback on the kind of impact this has on runtime, so if you have a flash target please consider giving it a try and reporting your results :)

Note that you will need to disable album art in your build for this to work. I don't even know what would happen if you don't, but it'd probably be bad. To disable it you need to comment or remove the #define HAVE_ALBUMART line in your target's configuration file (firmware/export/config-[TARGET].h).