Player Type = Sansa Clip+ (not available in chooser when submitting).
Release = 3.11.2

Recording at 48kHz results in audio that is 2.35% too fast. I believe it is recording at 49155Hz instead of 48000Hz. Recording at 44.1 kHz does not have this problem.

I have verified by putting 2 identical Clip+ in front of me, one set to rec at 44.1 other at 48.0. When playing back audio (on PC) difference in pitch is (barely) audible. And the audio falls out of sync as recording progresses (in video editor).

For now I’ll be happy to only record at 44.1kHz, but maybe 48kHz recording should either be fixed or dropped from Clip+ options.

Creative ZEN device build 8fec364f6-170125

Steps:

1 Clear Running Time
2 Shutdown, to ensure Running Time clear takes effect
3 Launch Rockbox
4 Record wall clock time
5 Leave running for a few hours
6 View Running Time and compare with elapsed time on wall clock

Expected: Running Time equal to elapsed time
Observed: Running Time less than elapsed time by 2%

Note: battery_bench.txt times accord with elapsed time.

This patch adds does three related things:

- Adds *basic* support for seeking and buffering callbacks so different codecs may manage their buffer space differently
- Extends a few buffering and metadata structures to store information on two files rather than one
- Modifies the Wavpack codec to make use of these features to play back hybrid files with readable correction files losslessly.

This code should not in any way interfere with anything other than the situation where a Wavpack hybrid file is present AND its correction file is readable.

There are several things that need to be done before this patch may be committed:
1. Currently there are two ginormous linear buffers inside the Wavpack codec. They should be replaced with smaller dissimilarly-sized ring buffers.
2. The interspersal of primary and correction file chunks is currently 1/1/1/1. This should probably be more like 1/3/1/3 as that better matches the size rations of a .wv to its .wvc.
3. seek_wavpack needs to support seeking where rebuffering is required.
4. The wavpack hybrid decoding function needs to be modified to decode smaller chunks in a go so that the small ring buffers mentioned above won’t overflow.
5. Gracefully handle the end of a hybrid lossless file (currently it freezes the sim)

It's Seems to be no support for RTL languages like Hebrew and Arabic in rockbox for android.
Instead of מוסיקה written הקיסומ (in English - Instead of "Music" written "cisuM).
I attach pictures for example:

ROLO currently fails on these targets unless a Rockbox image is being loaded that is sufficiently similar to the one already in memory.

The sequence goes like this:

- rolo_load() loads the new image to
rolo_restart() copies the new image to the start of DRAM (to achieve this without crashing, this function is in
rolo_restart() tries to call invalidate_idcache(), but since invalidate_idcache() is in DRAM this fails as the function has been overwritten.

There are several solutions to this:

1) Move invalidate_idcache() into .icode (easy but won’t fix all targets, esp. those that don’t use IRAM)

2) Create a new .safecode section at the end of DRAM, and move these functions into it (lots of work to update every app.lds and crt0.S, and test every target)

3) Introduce target-specific rolo_restart() functions, as per imx31/rolo_restart.S (less work, as only one should be required per architecture, eg ARMv4/5 etc.)

I’m not sure which of those options is “best”. 1) is certainly the easiest, but 2) and 3) should also allow ROLO to work on targets that don’t use IRAM.

This patch should apply to all ipods, but needs testing - on both a mixture of ipods and mixture of operating systems. I’ve tested it successfully on my Color with both Linux and Mac OS X.

Current SVN behaviour is to write some magic to the end of IRAM and reboot the ipod when a USB connection is detected. This causes the Apple bootloader to start the disk mode application which is stored in flash ROM.

This patch cuts out the reboot stage and uses rolo to start the disk mode application directly from flash - meaning the ipod enters disk mode almost immediately. This is done in a new rolo_load_rom() function which copies the image from ROM to RAM and then executes it.

ROLO is broken on Nano 2G 3.10RC. It just says: Executng… and freezes. Seems to be happening not only for me:

http://www.rockbox.org/mail/archive//rockbox-archive-2011-11/0070.shtml http://www.rockbox.org/irc/log-20111105#23:01:01 (is this also related?) http://forums.rockbox.org/index.php?topic=28467.0

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

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

Hello,
I’ve recently designed new text editing plugin for Rockbox, which I called (how original…) rockedit. The point is not to compete with current text_editor, but rather to develop a new approach to text editing by, in particular, allowing user to work in insert/replace mode. The major difference is that the keypad has been replaced by a single which the user navigates through using up/down, while left/right are used to change current char. Fire key is used to switch between different chars lists.
I didn’t manage, though, to use keypad as set in r17659. The diff file just reverts it, which is not a good solution at all… Furthermore, I haven’t tested it on any other target but my gigabeat : I cannot boot Windows currently.

I’ve included a patch which includes keymap changes, and another which doesn’t. I’ve also added a screenshot.
Please do comment and help me improve this editor !

When trying to start RockDoom on the iPod Classic, Doom appears to load normally until the iPod crashes and says "Prefetch abort at 71D0BF24 FSR (domain 0, fault 5)". Build ver. 8abdd9b-120902

Hi there,

i am currently trying to learn the morse code. I thougt it would be fun to have rockbox as an aid, so i started to write a plugin for that.

This plugin currently has a limited functionality, but the current things are implemented:

1. Morsing of custom texts, typed from the rockbox keyboard
2. Morsing of random chars, till the battery drains (or less ;))
3. Input of own Call and 'morsing' the same
4. selection of speeds from 1-45 WPM in steps of 3
5. selection of chars from 5 mixable groups
   1. letters
   2. numbers
   3. punctuation marks
   4. special chars (KA,BT,AR,VE)
   5. pauses

It would be very nice if someone tested these on some soft-codec targets. I included the source tarball (please add plugin to SOURCES and CATEGORIES if using this), a diff on r17715 and the binary .rock for the sansa c250.

Idd be very happy if, with a little help, this could move upstream. I am new to the plugin api and need some help especially in using the definitions to make this work on different DAPs (avoid building this on targets that don't support some features and so on). Correct me if i am wrong, but his should from my point of view work with all SWCODEC devices with LCD. I tried to write at least readable code and added some comments for the curious.

This builds at least on the c250 and works for me.

Thanks, Joel

Remind me, if i forgot something.

The volume settings are bypassed and is at max volume when the plugin is started. Even when putting it at -60DB it still has sound. After exiting and relaunching the app,the volume is maxed again,regardless of volume settings.

(sansa fuze)
for some games (such as pokemon)
when you walk around alot;
it is difficult because even the slightest movement of the wheel activates the pause screen;
I have tried multiple controls setups;
and whatever is setup to use the scrollwhell is always extremely sensitive;
a sensitivity setting should be added, to allow a change in the threshold required to count as a button press

Sound in all games sounds like chirps or clicks that sounds kinda like the real music on the Nano2G.

The patch reorganizes Rockboy to use the same method for storing GB frame buffer data on greyscale targets as color targets. As a result, support for greyscale iPods is much easier and has been implemented (inspired by FS #5282).

Some other changes include:
- Enable the menu for iRiver H100
- Ability to “Show Stats” on all targets
- Screen is redrawn all at once on greyscale instead of line by line
- Elimination of fb.mode (all targets use options.scaling for scaling options)
- Elimination of fb.cc on non-color targets
- Minor variable renaming
- Unification of LCD variables (vdest vs frameb)
- Move greyscale LCD code into lcd.c
- ifdef out vid_update() on greyscale and color targets

Since I don’t have an iPod, I’m curious to see how well this works. It should be fine since the patch my work is based on seems to work for people.

I really need iRiver H1X0 users to test this. There are significant changes to the LCD code and I’d like to know if the is any speed change, whether its an improvement or not. I’d guess that it’s slightly faster or the same as SVN but there’s always a chance that it is slower.

I noticed, that every time I’m in the car listening to music, and I disconnect the iPod 30G (5th gen), while its playing, and I then try to shut it down, it’ll jump to the main window and will not move away from it.

From this point on, I cannot turn off the device nor more away from the main window. Only a HR will resolve this and let the iPod come back to normal working order.

Further more, while it is in that situation (which it is right now, while I write this), the device won’t even go on sleep or turn off the monitor. So basically, it’ll stay with the screen wide awake and lit up.

The two only buttons that will work are the Hold button, which will in turn, turn off the screen and the scroll will allow me to scroll up and down and around on the main window.

Q: What sort of car connection do you use? Line-out+power, or MSC? Or the accessory
I’m not familiar with these connection and their types. All I know is that it is connected to the car stereo from back (ie. the stereo was pull out and the adapter was connected in the back). Also, that it is a connection that connects to the bottom of the iPod (ie. flat and wide connection). It gives me control from the car’s stereo and the steering wheel. When I bought it and then they hooked it up, they told me this is an iPod adapter.

This DOES NOT happen if first stop the music and go to another menu BEFORE I disconnect it from the adapter.

The manual offered by Rockbox Utility is not necessarily the version that accords with the installed (or to-be-installed) program.

E.g. select Release 3.13, and the Manual offered is http://download.rockbox.org/manual/rockbox-sansafuze.pdf not http://download.rockbox.org/release/3.13/rockbox-sansafuze-3.13.pdf .

http://www.rockbox.org/irc/log-20140124#15:41:22 says this is a bug. Since the user does reasonably expect a manual to accord with the program, I too think this is a bug. Whether it is a design bug or code bug, I cannot guess.

Note: this task says Operating System: All players but only because the actual player, Sansa Fuze, is not offered. Though this issue may indeed apply to all players.

This is basically a documentation update. For several years I generated accessibility voice files on my devices. Then one day I was reinstalling and it would generate a lot of the voice files but die from a weird error. For more than six months I combed the manual and the forums, trying to figure out what had changed, trying to debug it myself. Eventually I stumbled across the problem. I had noticed the “install on player” option in Rockbox Utility and started generating voice files while running from the player. Once I switched back to running Rockbox Utility by launching the utility from my regular PC disk, everything worked again. I again looked for any warning about this in the manual, and didn’t find anything.

The simplest fix is to include something about this in the section on accessibility and generating voice files.

Another fix, probably not worth it, would be for the voice files to use system tmp space for intermediate files. I suspect that the recursive generation of talk files on player ends up in some infinite regression as it generates talk files for temporary files.

This probably happens on all players, but I only experienced it on the iPod Nano 1st Gen.

r28936, sim build for iriver H120, fresh installation folder, i.e. no file “config.cfg”

I modified the function “sim_open” to ouput what files it’s opening, and got the following output (see attached text file). Note that there are files “-.kbd”, “-.sbs” and “-.rsbs”. I think these files should not be opened, even tried.

So, I have a Clip Zip at the moment. Been using rockbox on it since day 1, and since day one i've always had an issue: during playback, when accessing files from the SD card, the player randomly freezes. It's not always, it's not when accessing the same files or some specific characteristic shared by them, it just appears to be random. When it freezes, the LCD usually still responds to my commands (i can access menus, see the file info, even change song and it will display in the playback screen), but the actual playback doesn't, and I eventually have to hard reset it. I guess it's some kind of SD compatibility issues: I have an 8GB class 4 PNY. I know it's not the own card's problem since it worked perfectly on my Clip+ and does on my Android Cellphone.
I've been updating daily builds for this device at least once a week since I got it, and it happens with every build.

I primarily use my unit for audio books while driving, but the latest build (as I write this) won't play one of the files properly. It tries to start, stuck at 0:00. Trying to seek hangs the player altogether, requiring a hard restart.

I've recreated this problem on a flaky Clip+ and an AGPTek Rocker.

The 'file' tool identifies it as: ISO Media, MP4 v2 [ISO 14496-14]

Here's what mplayer has to say (while playing it back properly):

[lavf] stream 0: audio (aac), -aid 0, -alang eng

Rockbox hangs if the disk gets full during database creation.

charging isn’t monitored on ipod 3G. it just goes up to 100% very quickly and stays there.

this is ordinary mp3 file.
I think it was name problem, renamed to simple.
Still not play.
Player Sansa Clip+ (not found in bug report menu)
Rockbox 3.12 (not found in bug report menu)
Standard firmware has no problem with this.
Good luck!

It is 16Mb size so I put it to my dropbox
https://dl.dropbox.com/u/17669498/rockboxbug/08.mp3

Hello

I run rockbox daily (last update 27 Feb 2014) and found an issue that I like to report. I have my sandisk clip zip connected to an external USB hub, which is connected to my notebook. Today I left the sandisk clip zip connected and turned the notebook off. I expected that the player will disconnect from the USB hub → blanks the screen after 20-30 seconds (depending on the setup) and then turns off after a while (depending on the setup). Unfortunately the last step won't happen.

The sandisk clip zip really disconnected from the USB connection (the usb picture disappears from the display) with the notebook going back into the rockbox menu (Play, Radio, Settings, Recording etc.) and after a while also blanks the screen as expected.

Unfortunately it does NOT turn itself off as it would if you leave it entirely unconnected (unwired) with the USB. The sandisk clip zip starts to turn the screen on again after a while, turns off again, turns on again after a while, turns off etc.

I had to plug off the mini USB connection (the wiring between the player and the usb hub) so it turns off and shuts down after a while.

What I believe is, that the USB subroutines might not know the difference between powered on notebook and powered off notebook. It only knows that it's wired and thus tries to turn the player on again after it blanks. It should really be possible to keep the player connected (and wired) when the notebook shuts down and have the player shut down as well (after blanking and then turning itself off).

Could this be reviewed and maybe worked on ?

Thanks so far.

I am trying to build Rockbox for Sony NWZ-380 from Git repo, commit ce0b31d87db3c4c1c1bfb535c50770d33e9c4aaf.
arm-elf-eabi-gcc version 5.4.0, ARM binutils 2.30.
Everything goes smooth until just the latest step where this happens:

… LD duke3d.ovl
LD bmp.ovl
LD jpeg.ovl
LD png.ovl
LD ppm.ovl
LD gif.ovl
LD rockbox.elf
/usr/libexec/gcc/arm-elf-eabi/ld: section .ARM.exidx VMA [00000000600a9548,00000000600a954f] overlaps section .bss VMA [00000000600a7f20,00000000600ff773]

I'm using Rockbox on my NWZ-384 for a couple of years now and there were no problems building it in the past. I also was very glad that NWZ-380 port reached stable status in 3.14,
but now something seems to be broken (not terrible it seems, just requires some adjustments to the linker scripts but still).

For the last couple of weeks, I can’t get Rockbox to run anymore on my phone. I use Rasher’s build, which used to work fine. I even built one on my own, but it still doesn’t work. I tried running it on the emulator and it worked fine. I am not sure what is wrong, reading the logcat gets me nowhere because I don’t really understand most of it. I have attached the logcat here. I do not know if I’m the only one having this problem.

I tried various method to get it working again on my phone, I even tried resetting my phone in case if I messed up somewhere. I also noticed this when I was trying out another ROM for my phone, which runs on Gingerbread 2.3.7. I thought it was the ROM’s problem, so I changed back to the ROM that I frequently use, which used to had no problems at all running Rockbox. The last working build was on 01 March 2014, after that, nothing works anymore on my phone.

The only possibility that I can think of is that my phone is outdated and the kernel or the ROM is missing something crucial to run the latest Rockbox builds. Other than that, I have no idea. I hope the logcat attached could help you identify this problem. Thank you in advance.

Build version: 915bc09-140318
Last working build (on phone): unknown revision, dated 01 March 2014
Phone: Sony Ericsson Xperia X10
Android: 4.1.2 Jelly Bean (CyanogenMod 10)
Emulator: 4.1.2 (API 16) with same screen dimension.

This may represent other players as well.

I installed a new battery on my iriver, a 2100 mAh that is working perfectly. The problem however, is that when fully charged, the voltage holds up to 4.12 volts, and until it drains to somewhere under 3.9 volts, Rockbox thinks that it is powered via USB, so naturally Rockbox gets stuck in USB mode until the battery is drained enough for Rockbox to realize that it IS a battery. With this problem at hand, I have to charge my iriver to only less than seventy percent of its battery life, or else wait for an hour or so to drain it to that point. I HAVE tested it in its original firmware, like I said, works perfectly. The problem lies with Rockbox thinking that the battery is a USB charger. I am asking for a fix around this. Is there a way that I can modify Rockbox so that it may understand that it is running off of a battery that will get up to 4.12 volts and not mistake that for USB power? I just now thought to turn off the “Charge During USB Connection,” maybe that will solve the problem; I will get back when I find out whether or not that works. However, I would still like to request a work around for this problem. Any help is much appreciated. Thanks.

When Playing with rockboy on sansa e200 V1 , Rom that have a size of more than 1m Bug and Rockbox often shutdown. And even if these roms run, the speed isn't playable.

After updating Rockbox from 3.10 to 3.11.2 on my Ipod Nano 1g i noticed the robotfindskitten game did not work as it should anymore. When robot has touched the first object, the text on the top does not change anymore when touching more objects until he finds kitten. The kitten animation also is hidden behind the text of the first object and the scrolling of the text starts at the end, not at the beginning.
I think it worked fine in 3.10, or at least in 3.9.

Please investigate this problem.
Thanks,
Hugo

Building Rockbox fails if assert() (in firmware/include/assert.h) is used.

Then, I reworked assert.h.

changes:
When assert() failed, the correction that displayed the file name, the number of lines, and the condition of failing was done.
Moreover, when the log was enabled, the log was output to the file.

Please select the following to make assert() enabled when you make Rockbox.

1) Run tools/configure

2) Build (N)ormal, (A)dvanced, (S)imulator, (B)ootloader, …

    Select "A"

3) (D)EBUG, (L)ogf, (A)ssert, (S)imulator, (P)rofile, (V)oice

   Select "A"

4) make

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.

After upgrading from "Version: 33856d9-161111" to "Version: 6436c6e-170211" Resume Playback from the main menu does not work. Here are the steps taken to verify the problem:

Running Version: 6436c6e-170211… Reset config
Using default settings, enabled Shuffle via Shortcuts
Started playlist; track identified as 1 of 5330
Skipped ahead to the 5th track
Paused @ 1:01
Forced shutdown
Enabled Hold switch
Waited ~1 min., then booted via disengaging Hold switch
Clicked Resume Playback… resumed on the same first track (1 of 5330)
This behavior occurred every time I attempted to Resume Playback.

Restored previous version (Version: 33856d9-161111)
Rebooted
Reset Settings
Using default settings, enabled Shuffle via Shortcuts
Started playlist; track identified as 1 of 5330
Skipped ahead to the 5th track
Paused @ 1:01
Forced shutdown
Enabled Hold switch
Waited ~1 min., then booted via disengaging Hold switch
Clicked Resume Playback… resumed on the fifth track @ 1:01

FWIW: No Bookmarking used (never have). Database not initialized (never use it).

This patch should save pitch and speed settings to nvram, and restore them after reboot if needed.

If I read the code correctly, there should be enough room in nvram (and anyway, the way this is done doesn't apply to any targets that actually use real nvram)

This code compiles, but apart from that it's completely untested.

Of course, since this patch increments the nvram data version, you'll lose resume info the first time you reboot.

r28529

This patch adds a new library that creates a calculator-like keyboard for easy number entry as an alternative to the on-screen keyboard. A lot of the code for drawing the buttons was taken from the calculator plugin.

Tested on the e200.

r28528

This adds a bitmap to be shown as the output of the 3 modes of the calculator, similar to the color-codes on the color targets, except that it is a static image for the greyscale targets. Might as well use the screen space for something.

I tested this on a clip+ (3.13) and creative zen (rev cc64d9e), so assuming it’s the same for all devices.

Following setup:
- ReplayGain is configured to “Track if Shuffle” - “Prevent clipping” is set to on/off, does not matter

How to reproduce:
- make a copy of any RG scanned file which has track/album gain and peak tags
- remove the peak tags _only_, leaving gain tags intact

Expected result:
- player should be able to adjust the volume, but not prevent clipping

Actual result:
- player does not apply neither track not album gain.

Files containing only gain tags but not peak tags come from converting lossless → lossy and transferring gain info (since peaks will be different for the lossy file, peak tags are omitted.) With 11db of volume difference on some tracks, it’s impossible to not notice that. I am not sure why applying RG requires peak tags in rockbox, foobar2000 handles peak tag-less files without issue. Any chance to change this behavior to not rely on peak tags?

I use the attached custom WPS that displays the active Replaygain value and type next to the track number.

When playing mpc files created by foobar2000 with the tracknumber/totaltracks tag format, if the track# is 10 or higher and the applied gain negative (as in the attached mpc), mangled characters are displayed between the gain value and type, eg:

10/12 -2.00 dB *gibberish* (Album)

This is reproducible with the latest simulator build d0fffd6-150104 but I only recently noticed the issue and don't know when it began. I have an old sim build 935d8be-121229 and it works correctly there.

Dumb patch but introduces handling for non triangular faces (by triangulating them when rendering). Vertices courtesy of http://mackayj.doosh.net/eliteships.html (in particular I hand-converted http://mackayj.doosh.net/files/vrml/eliteships/cobra3.wrl)

This patch removes any total tracks and total discs number from the track and disc number fields in ID3v2 tags, so that track and disc numbers are displayed consistently across different tagging formats.

What happens is that if a number larger than zero can be parsed from the start of the field, then the field is terminated on the first “/” char.

Added as a patch as I don’t know if this behavior is wanted.

This patch removes the Repeat:Shuffle setting, and always reshuffles the playlist when Shuffle is set to yes and Repeat is set to All.

The rationale behind this is that a user would rarely want to shuffle the playlist the first time only and always repeat the same sequence afterwards. Rather, one would either play the playlist in order and repeat in the same order, or shuffle the playlist first and always reshuffle.

Setting combinations affected:
- Shuffle:Yes && Repeat:All

before: shuffle the playlist but repeats the same sequence
after: shuffle the playlist and reshuffles when the end is reached

- Shuffle:Yes && Repeat:Shuffle

before: shuffle the playlist and reshuffles when the end is reached
after: this combination is replaced by Shuffle:Yes && Repeat:All

- Shuffle:No && Repeat:Shuffle

before: reshuffle when the end is reached
after: rarely used combination, not available anymore

All other combinations are not affected.

The patch contains some comment fixes and some code simplification as well. We also have to handle a special case in the patch.

i asked some time ago why there is the buttontable in general settings –>bookmark. i wondered because the buttons are the same as in other lists. Marc Guay said "the delete button is unique", an i wondered why there is a dedicated delete button… in no other lists exists such a button afaik.

i changed the manual accordingly.
i also corrected some wrong (?) comments.
i hope i did everything right, at least for the e200 it compiles and works fine.

i would like to get some opinions about it.

Hi all.

I have found a funny thing, which should get fixed. In set_prescaled_volume there is this call:
audiohw_set_lineout_vol(tenthdb2master(0), tenthdb2master(0));

As far as I can see this call is not needed here. So this patch removes it, but as I own only a sansa e280 I can not test this change. I hope to commit this soon.

If this call is needed… do we need it every time audio changes or only once at init?

Thanks,
AustrianCOder

Pressing the remote volume UP key on my iriver 140 in wps sometimes results in directory skip.
This is not easy to reproduce, but I was able to repeat once that problem in conditions where I'm sure that the directory skip key wasn't pressed.

I don't know if it's a hardware related problem, but I've read somewhere about another user having the same problem.

This attempts to implement the idea in http://forums.rockbox.org/index.php?topic=25169.0 this only works for the Settings menu in the main menu.

With this patch, if you reenter the Settings menu, it shows the menu shown when you leave the menu just like when you return to the browser or the database.

This bug currently exists as of rev 21444.

If settings are modified on the recording screen they aren't persistent after a reboot unless another setting is changed somewhere in the menu system.

The problem is that global_settings is being modified without a subsequent call to settings_save().

Attached is a fix for this problem. I've so far only tested it on the h1x0 simulator but I think it's a pretty benign change, unlikely to cause problems on other targets.

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.

On my Sansa Clip+ 4GB, with Rockbox v3.11.2

Recording a wav file through internal microphone. If the audio signal clips at the positive limit, bad things happen:
1) Most of the time the recorded signal wraps around to a full scale negative value, which makes it sound terrible.
2) Sometimes the recorded signal wraps around to a near zero value, which still makes it sound terrible but the distortion is not so loud

3) Clipping at the negative end of the range is as you would expect - a flat line which sounds like normal digital distortion, as you would expect

See attached picture of the recorded waveform showing each of the 3 situations described above.

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).