All Projects

A (maybe too) simple fix for the unusable keymap on iriver introduced with r21034. Switches PLAY and REC keys.

Recording screen converted to viewports, no longer using sysfonts

To do
- clean up the code (not committable yet)
- convert LANG strings from SYSFONT to normal
- make the peakmeters nicer now that they can become big
- test on more targets

feedback welcome

example screenshot: http://users.telenet.be/petur/recscreen.png

Proposal to make rockbox work on targets with CF cards (modded)
Assumes identify[0] == 0x044A as CF detection
Also changes some minor stuff that I think was wrong.

The important change for CF:
- don't set powermanagement
- don't perform perform_soft_reset()

To reproduce:

- Be at about 10 seconds from the end of a song
- Stop and powerdown
- power up and resume playback
- skip back to start the song again

after some seconds playback skips to the next song automagically

Gain (and probably other) settings made in the recording screen aren't saved to disk. It looks like the disk spins up but at next boot the old values come back up.

This patch brings back the automatic rolo question you used to get after usb disconnect (and copying a new build of course)

It's here and not committed because this version scans at boot which is not very efficient imho. Any ideas are welcome

When the H300 is playing and backlight is off, pressing a button freezes the player solid - backlight doesn't come on and a hard reset is all that helps.
Note: doesn't happen all the time, I seem to have it only when it is playing for some time as I can't reproduce it just like that.

Possibly related: on other occasions, pressing a button only makes the backlight come on, the key itself is not processed. I have the 'First keypress' option off. This also doesn't happen always.

- Play a WAV file for some time
- Rewind back several minutes
- observe that when playback resumes, it’s actually playing from a point *past* your original playback point, not the point you were seeking to.

This happens if you seek back so much that you end up in a part that’s no longer buffered

Had a crash at the end of a recording.
After recording almost 100 minutes I pressed stop and after a short pauze it gave me (if I remember correctly) I04 at 00000002. It turned out it had saved the file ok, including the header, so no problem there.
Could be I pressed stop more than once but I'm _unable_ to reproduce.

Moos discovered that dircache kept giving the scanning splash, and I have traced the issue up to the point where it looks like the value never makes it to disk.

set_bits() encodes the correct value, but get_bits() reads 0. This I'm now 100% sure.

this works ok if using rolo, so it must be related to the actual spinning up and writing to the disk. Or maybe the disk doesn't flush its cache?

to test:
- disable dircache and reboot
- enable dircache, reboot
- next boots will always show the scanning splash because dircache_size is read from disk as zero.

Hitting stop while still reading the file to reach the resume point causes a lockup.

1) Play a fairly large WAV and seek quite far into
stop
start playback using ‘play’ to resume where left
press stop again before playback resumes (= while reading the file to rewach the resume point)

backlight thread still running but paperclip required to get a usable player again.

Observed on h340 but probably an issue on al SWCODEC

current CVS recording code is not stable. Missing samples (1-2 seconds) around the time of diskwrite, but not always. Maybe a timing issue/glitch?
example of 80 minutes recording:

missing samples at:
10:23 (delta 10:23 = 4 x buffer time)
15:35 (delta 5:12 = 2 x buffer time)
36:25 (delta 20:50 = 8 x buffer time)
52:01 (delta 15:36 = 6 x buffer time)
72:49 (delta 20:48 = 8 x buffer time)

A small patch to allow people to test if recording is still stable without boosting.
During writing to disk the cpu is boosted to write as fast as possible.
Not tested with digital recording.

Should decrease battery use during recording/monitoring considerably

Russian lang file does not load. Maybe related to the fact that it's the largest lang file?

See also http://www.misticriver.net/showthread.php?t=40829

When booting into the h300 iriver firmware, its settings can get messed up. Reported so far:
- illegal/wrong contrast setting
- illegal/wrong brightness setting
- changed/reset language setting

In the case of contrast, it was set to a value the iriver firmware couldn’t handle and caused it to behave wrong until a normal value was reached.

I was under the impression that iriver firmware stored its settings in the eeprom. Either we are messing with that or they store them elsewhere

now correctly disables IRQs before I2C bitbanging -
solves the problem of incorrect brightness at
startup/reboot

* corrects settings naming where adc_gain was used but
contained decimator gain (affects several files!)

* changes the way stereo channels are changed: puts a
selector on both lines to allow both channels to be
changed

* analog and digital gain merged into one big gain
range (always best quality) with indication if you're
changing analog or digital gain

NOTE: had trouble creating patch file, let me know if
there's a problem with it.

H300 brightness patch, replaces all previous versions

implemented in backlight.c and uses
HAVE_BACKLIGHT_BRIGHTNESS define

implements pre-recording for iRiver (H1xx and H3xx).
Includes safeguards for insufficient recorded samples
and too long pre-recording time.

Also fixes the occasional recording glitch by using
the circular buffer for recording start/stop

This patch makes patch 1384031 obsolete!

removes the start of recording noise

H300 recording enabled.
Has a glitch: the beginning of the WAV file has a
short burts of garbage.

Otherwise everything seems to work as on the H1xx

brightness setting added in driver (PWM tweaking) and
settings menu. Allowed values are 2..15

includes patch 1378276 (inline some calls) as well as
it was the same file

Inlined all register writing calls. Gives 1-2% speed
increase. About the same amount the patch of Kaggen
gave.

H3xx only.

Tried and tested code submitted to the mailing list by
Kaggen. No obvious speed increase but works
nonetheless. Unless the code isn't called.

Uses the HD66789R windowed access functionality to
only write a rect in the GRAM.

A small patch to reduce cpu load to less than 10%
while keeping playback as smooth as it was with 100%
cpu load

fade_insert() can crash if crossfade_fade_in_amount
hasn’t been set. Somehow this happens in the H3xx w32
sim, causing it to crash.