This patch changes the iriver H300 series bootloader's power and usb handling. When a USB or Power plug are inserted into the H300, it will now boot as normal, not stop in the bootloader usb/charging modes. This was mainly for use in my car, but is also helpful for people with charging cradles for their computers.

Forum thread can be found here http://forums.rockbox.org/index.php?topic=17202.0

I am trying to use the last method mentioned on the ipodpatcher wiki page to write Rockbox directly into the OSOS image on my iPod Nano2G. Sometimes it works properly, but other times it fails saying that it couldn't read the header from the .ipodx file. I am following the instructions exactly, so that can't be an issue. I have tried hexediting the .ipodx file, and in some cases I can get ipodpatcher to read the header by editing the first four values, but this always causes a Checksum Error. Here is the exact output:

C:\Users\Michael Marley\Downloads>ipodpatcher.exe -wf rockbox.ipodx
ipodpatcher 5.0 with v4.0 bootloaders (v1.0 for 2nd Gen Nano)
(C) Dave Chapman 2006-2009
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[INFO] Scanning disk devices… [INFO] Read XML info (4 bytes)
[INFO] Ipod found - 2nd Generation Nano ("winpod") - disk device 1
[INFO] Reading partition table from \\.\PhysicalDrive1
[INFO] Sector size is 2048 bytes
[INFO] Part Start Sector End Sector Size (MB) Type
[INFO] 0 63 48194 94.0 Empty (0x00)
[INFO] 1 48195 1982462 3777.9 W95 FAT32 (0x0b)
[INFO] Read XML info (4 bytes)
[INFO] Ipod model: 2nd Generation Nano ("winpod")
[ERR] Failed to read header from rockbox.ipodx
[ERR] –write-firmware failed.

The Idle Poweroff only reboots my 1G iPod. I assume it should power it off or put it into a power saving mode. This forces it to use up the battery faster then normal unless I set the Hold button to boot into the iPod firmware to do a proper suspend when Rockbox reboots.

H120 not starting original IRiver Firmware with LCD Remote holding Rec + Play Button both on LCD-Remote.

Since r30937, the e200v2 bootloader is too large and mkamsboot errors with:

[ERR] Packed data (120926 bytes) doesn't fit in the firmware (120860 bytes)

Steps to reproduce:
1. build e200v2 bootloader
2. cd to rbutil/mkamsboot
3. run make to create the mkamsboot utility
4. run mkamsboot <path-to-e200pa.bin> <path-to-bootloader-e200v2.sansa> <path-to-output.bin>

When using the H300 non-lcd remote to turn on the player (iriver H340) I get the following error message “hold switch on, power off…” (the hold switch is not on).

Alarm wakeup doesn’t work reliably. It is unclear whether the setup is wrong or the wake up is. It might be that the player wakes up before time because of a small press on the power button and thus somehow forgets about alarm.

Build 21245

I have ''Start Screen' set to 'Resume Playback'.

When connecting the Ipod (from OFF) to the PC the Ipod boots and USB mode starts but also playback (the play > sign is display on the title bar).

The Ipod is not shows and not mounted on the PC.

On disconnecting USB I get 'data abort' and have to hard reset.

This patch modifies bins.pl, manuals.pl and voices.pl to be smarter, just like the new w32sims.pl, adding a -r commandline switch, allowing the same script to be used for building both daily and release versions.

If you’re willing to produce a Human voice file (spoken by you or someone you know), this script will be particularly helpful. It expects you to put it in a directory with a subdirectory containing .wav files for all voice strings, named by the contents of the string (this will be problematic on FAT/NTFS, but could be fixed).

When run, it will check to see if all needed strings are available, and if they are, it will generate a voice-file for all targets. If they aren’t, it will print out a list of strings missing (to be recorded and put in the subdirectory). This list will also be put in the file “missingstrings.txt”, one on each line.

This might be suitable for inclusion in tools/

Edit: Script deleted. Will upload again soonish.

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

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

The Rockbox firmware and cross compilers build by using MinGW.

It is necessary to use MSYS’s make (MinGW’s make (mingw32-make) does not used.).

The cross_compilers.zip is a patch file necessary to make cross compilers using by rockboxdev.sh.

I confirmed the Rockbox firmware, codecs and plugins was built by using the compiler on MinGW.
But I can not confirm whether the Rockbox executes excluding iPod video.

Could you confirm operation to various players?

The H10 5G MTP needs a different bootloader than the UMS version (see http://www.rockbox.org/twiki/bin/view/Main/IriverH10PortDevInfo#Build_a_Rockbox_Bootloader).
I’m not sure about the correct way to do this in configure, so I’ll leave it to someone who is.

The patch fix the multiple-language feature, maintaining the same behaviour in interactive and batch mode and with “make reconf”. Now it’s possible to build more than one voice language at once, specifying different engine and option set for each one.
So, running “make voice”, all the selected languages will be built.

To help the comprehension, here it is a batch mode sample:

../tools/configure –target=ipodvideo –ram=64 –type=av –language=italiano,espanol –tts=f,e –voice=lp_diphone –ttsopts=, –encopts=’-q 10 -c 10,-q 5 -c 5’

This is like to run:

../tools/configure –target=ipodvideo –ram=64 –type=av –language=italiano –tts=f –voice=lp_diphone –ttsopts=’ ' –encopts=’-q 10 -c 10’

../tools/configure –target=ipodvideo –ram=64 –type=av –language=espanol –tts=e –voice=lp_diphone –ttsopts=’ ' –encopts=’-q 5 -c 5’

In the first case, I set the language to italian, using festival with voice lp_diphone (female), no further festival options and some manual encoder options.
In the second case, I set the language to spanish, using espeak. Even if I set the voice, the value is ignored, since the selected TTS engine doesn’t use it.

I also added some cosmetics, like some very circumstantial indentation, blank check in rootdir too, simpler numbered menu generation, some terser command pipes.

The patch is applied to r22250.

I don’t know if it’s a really wanted feature, but the word in the script hurt me!

When I try to build rockbox, I get the following error:

=⇒ make: execvp: /bin/sh: Argument list too long
⇐=

My build path is a fairly long path. Building it at a location with shorter path it works. Details:

Steps to reproduce:

* Create a location where you want to have the sources; use a fairly long path name, e.g.

  mkdir -p /home/myuser/download/mediaplayer_hardware/SanDisk/Sansa_Fuze_v2/rockbox/firmware/source/

* Change to that directory:

  cd /home/myuser/download/mediaplayer_hardware/SanDisk/Sansa_Fuze_v2/rockbox/firmware/source/

* Download git sources (Tried with version from 2014-09-22, 10:55:11 GMT+1, Commit by "Marcin Bukat marcin.bukat@gmail.com", Change-Id: "Ie3aa9b208e3f4f17d4d02f11f69839e9b381217d") to a long path:

  git clone git://git.rockbox.org/rockbox 

* Make a build directory and change into it:

  mkdir -p /home/myuser/download/mediaplayer_hardware/SanDisk/Sansa_Fuze_v2/rockbox/firmware/source/build_FuzeV2
  cd /home/myuser/download/mediaplayer_hardware/SanDisk/Sansa_Fuze_v2/rockbox/firmware/source/build_FuzeV2

* Configure the build:

  ../rockbox/tools/configure --target=63 --type=N

prodces the output

==>

Using temporary directory /tmp
Platform set to sansafuzev2
Normal build selected
Using source code root directory: /home/myuser/download/mediaplayer_hardware/SanDisk/Sansa_Fuze_v2/rockbox/firmware/source/rockbox
Using arm-elf-eabi-gcc 4.4.4 (404)
Using arm-elf-eabi-ld 2.20.1.20100303
Found and uses ccache (/sbin/ccache)
Automatically selected arch: arm (ver 5)
Created Makefile

<==

* Running "make":

  make

produces the output

==>

Generating dependencies
make: execvp: /bin/sh: Argument list too long
make: *** No rule to make target '/home/myuser/download/mediaplayer_hardware/SanDisk/Sansa_Fuze_v2/rockbox/firmware/source/build_FuzeV2/make.dep', needed by 'all'. Stop.

<==

and returns with exit code 2.

Workaround:

Building it in a directory with shorter path, e.g. doing everything in "/tmp", works.

But that is only a workaround; it should not fail when building in arbitrary locations, and especially not with a message not making it clear _what_ the underlying problem ist. (I had to do a long internet search to get to the idea that the build place can be the problem).

Trying to cross-compile GCC for the ipod with GCC 9.2 I keep running into errors:

In file included from ../../gcc-4.4.4/gcc/diagnostic.h:25,

               from ../../gcc-4.4.4/gcc/tree-mudflap.c:43:

../../gcc-4.4.4/gcc/pretty-print.h: At top level:
../../gcc-4.4.4/gcc/pretty-print.h:310:6: error: ‘cgraph_node’ is not defined as a type

310 |      ATTRIBUTE_GCC_PPDIAG(2,3);
    |      ^~~~~~~~~~~~~~~~~~~~

This would seem to be the same issue as the one described on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90677

The attached patch against GCC seems to fix the problem for me.

Hi,

There is a compilation problem when the environment variable BLOCK_SIZE is set. It gave me errors about a comma.

This can be set or cleared systematically or on a command by command basis.

Suggestion one; unset BLOCK_SIZE and its relatives high in the build chain, but be prepared for POSIX to bite with 512 byte blocks.

Suggestion two; set LS_BLOCK_SIZE=1 high in the build chain. (And DF_BLOCK_SIZE=1024 and DU_BLOCK_SIZE=1024 ?)

Suggestion three; edit apps/lang/Makefile so that

$(SILENT)echo “#define MAX_LANGUAGE_SIZE `ls -ln $(OBJDIR)/* | awk ‘{print $$5}’ | sort -n | tail -1`” > $(HEADER)

becomes

$(SILENT)echo “#define MAX_LANGUAGE_SIZE `ls -ln –block-size=1 $(OBJDIR)/* | awk ‘{print $$5}’ | sort -n | tail -1`” > $(HEADER)

or

$(SILENT)echo “#define MAX_LANGUAGE_SIZE `LS_BLOCK_SIZE=1 ls -ln $(OBJDIR)/* | awk ‘{print $$5}’ | sort -n | tail -1`” > $(HEADER)

Suggestion four; just tell people that they are not allowed to have commas in their core utilities output (and be prepared to be bitten badly if the default block size ever changes).

BTW I *like* having thousands separators on my command line, so I have

export BLOCK_SIZE=\'1
export DF_BLOCK_SIZE=\'M

in my /etc/bashrc file.

Tested at r29689, gcc 3.4.4. When trying to create a voice file in Cygwin, the following comes out (taken from STDERR):
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x453): undefined reference to `_speex_nb_mode'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x45a): undefined reference to `_speex_wb_mode'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x462): undefined reference to `_speex_encoder_init'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x490): undefined reference to `_speex_bits_init'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x4b9): undefined reference to `_speex_encoder_ctl'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x4d9): undefined reference to `_speex_encoder_ctl'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x4f6): undefined reference to `_speex_encoder_ctl'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x513): undefined reference to `_speex_encoder_ctl'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x527): undefined reference to `_speex_encoder_ctl'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x5fd): undefined reference to `_speex_resampler_init'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x609): undefined reference to `_speex_resampler_skip_zeros'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x6ac): undefined reference to `_speex_resampler_process_int'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x6fc): undefined reference to `_speex_encode_int'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x724): undefined reference to `_speex_bits_write_whole_bytes'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x7c0): undefined reference to `_speex_bits_write'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x81d): undefined reference to `_speex_encoder_destroy'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x829): undefined reference to `_speex_bits_destroy'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x83d): undefined reference to `_speex_resampler_destroy'
collect2: ld returned 1 exit status
make[2]: * [../rbspeexenc] Error 1
make[1]: * [rbspeexenc] Error 2
make: *** [voicetools] Virhe 2

The uisimulator cannot be build by using the source of the latest version on MinGW.

I send this bug’s patch.

It is necessary to apply the patch of FS#10021 to build the firmware on MinGW.

This is an attempt to automate the setting of $PATH in tools/rockboxdev.sh, tools/configure and the generated Makefile.

The directory prefix of the cross compilers is stored in ~/.config/rockbox.org/RockboxCompilerPrefix. As the default path (in tools/rockboxdev.sh) is /usr/local, if that file is empty, then $PATH won’t be modified. Otherwise, the value stored inside that file will be read, the target platform type appended, and lastly /bin appended. The resulting string will be appended to $PATH.

This patch doesn’t break existing configuration. But it’s most probably incomplete, so please provide feedback on which files need to be modified as well.

These two scripts will, if you run them appropriately generate a few screenshots in an automatic fashion. Execute it like this, from inside a simulator: ./genscreenshots e200.xte /path/to/output

There are a few pitfalls:
* The simulator window MUST gain focus when it is run. If this doesn’t happen, everything breaks. Horribly.
* The method is rather timing sensitive. I had to put a pause of 250ms between each keypress to make sure they registred (too fast, and the sim/SDL would discard them). 250ms may not be the right amount for your computer.
* Rockbox itself is also timing sensitive. If you “push” a button at the wrong time, it may not register, so use plenty of sleeps to make sure things are settled.

Edit: Oops, the first version had a hardcoded filename. Hopefully of such things.

It would be useful to change the configure and voice.pl files in order to allow the user to choose also the Loquendo and ViaVoice TTS

This patch adds a new codec that playbacks ZX Spectrum .tap files. Created against trunk (revision 31187)

decode_packet in wmaprodec.c returns -1 almost immediately, most likely due to being passed corrupted data by the ASF parser, although I have not confirmed that to be the case. I've seen similar issues in WMA Std. Theres probably some ASF feature we do not correctly implement.

Hello World :)
Attached is a VBR WMA music file, which fails to play correctly on my “RockPod” iPod Nano.
The same file decodes perfectly using the latest ffmpeg build.
Therefore I can only assume there is something about this file which triggers a bug in the Rockbox-specific WMA decoder.
Also attached is a microphone recording of the sound which comes out of my iPod when Rockbox attempts to play the faulty WMA.

I have over 3000 WMA tracks, all encoded using an identical method, all of which will not play correctly in rock box, so if you would like any more examples, or information, please ask.

Thanks for all your help :)
(If there is any way I can help debug/update the code for the wma decoder, please let me know where to start, I understand the C source code pretty well)

~Andrew

All i know is that this happened on 590mb tta file and after cutting it with cue splitter there was no problems with playback.

SVN:31187

This first patch is a merge of Tremolo’s bitwise.c and bitwiseARM.s code into rockbox libtremor. As a naive version of the merge, I have taken out the previous rockbox optimisations to huffman decode (originally implemented in  FS#6848 ). Versus svn, decoding speed is worse with this patch. However something that incorporates both  FS#6848  and the Tremolo bitwise optimisations for little-endian ARM may well turn out better. This patch is seriously not committable, the arch-specific stuff is not done cleanly in the headers or the makefile

I have only tested this on my H120 with an 18007 build. I have been using the APE codec for some time now and never had a problem in the past.

After reformatting my hard drive and installing the current build I found that rockbox has 2 problems with my APE files

1. The parser for APE files no longer recognizes my APE files encoded with version 8,9 of Jriver Media Center. Result is that files don't play when selected in the file browser and these files do net get added to the database.

2. When switching APE tracks one of two possible behavior occur. a) the Iriver freezes completely. b) On switching tracks there is a loud hiss and then playback of the next track resumes.

Cheers

  Thomas

Playing 320K MP3s pauses often in Version 3.15 and daily build 7d00533 also UI becomes unresponsive
Version 3.14 or older does not reproduce the issue in either 44 or 48khz sampling rate and same sound options
Is not reproducible under OF or Version 3.15 running on IPOD 6G
seems to be a cpu usage issue as compiling a version of rockbox with much higher than stock CPU clocks seems to alleviate the issue to an extent but there is still occasional pauses that is not present after reverting to 3.14 and stock 80 mhz clock speed.

When I play non-protected WMA files of 32 - 64 kbps and 44khz which have been ripped without changing anything from video on my Clip+ I get a garbled sound. I hear bits of sound all mixed up. This was true w/ 3.81 firmware and now w/ 3.9. The unexpected thing is that they all play normally w/ the Sansa firmware(Sansa firmware's volume is too soft for my taste Roll Eyes).

This is actually release 3.5.1

I have quite a few low bitrate .wma audio files that play fine in the original firmware, play fine in VLC, but skip, stutter, and hiss in Rockbox.

The file is 20kbps, 22 kHz, mono, Windows Media Audio V2.

I have attached a sample cut from a larger file. Like the original files, it plays fine in the original firmware and in VLC.

This patch makes some changes to codec_api to help remove dependencies for my project.

The unused strcasestr callback is removed.

The global_settings pointer was being used by several codecs to check whether REPEAT_ONE mode is on; this has been replaced with a callback "should_loop()".

The MOD codec has been modified not to restart the file when it reaches the end. This does not affect MOD files that use "position jump" to loop part of the song. Ideally the MOD codec would only follow such loops if should_loop() returns 1, but detecting loops is nontrivial.

The .ape file I join make rockbox produce a horrible noise (like random audio) when seeking inside it. The original file was very large, so I created this one with:
dd if=original.ape of=test.ape bs=512 count=1000
So the produced file may not be correct, but it plays correctly in rockbox, and reproduces the bug, so I join it…

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!

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

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

Continuing from FS#12240, these patches remove most of the rest of the dependencies librbcodec has on the rest of Rockbox.

Continuing from  FS#12204 , these patches remove some of the dependencies librbcodec has on the rest of Rockbox.

0001: puts equalizer settings in the parameters of dsp_set_eq_coefs, removing the need to access global_settings from dsp.c

0002: makes dsp_process yield each iteration instead of once each tick, which is tricky to do portably. If this is undesirable, I can work around it.

0003: moves some replaygain stuff around so dsp.c doesn't have to access global_settings.

0004: instead of dsp.c and tdspeed.c allocating buffers, buffers are allocated elsewhere and passed to dsp_timestretch_enable(). The necessary buffer size is determined by calling dsp_timestretch_get_buffer_size().

0005: replace get_audio_base_data_type() with audio_format_is_atomic(), removing a dependency on TYPE_PACKET_*.

0006: move autoresumable() to playback.c, removing another dependency on global_settings.

I have some stereo files that need to be encoded as two independent channels with no lossy stereo coupling. I encode these files by passing "–uncoupled" to the Opus encoder, e.g.

opusenc –bitrate 64 –framesize 60 –uncoupled example.wav example.opus

The lossless flac version of a sample of such a file prior to encoding can be downloaded from
http://kyle.tk/binaural-beat-sample.flac

If I do not pass the "–uncoupled" option to the encoder, the resulting Opus file plays with no trouble on my Sansa Clip+. The sample of this encoding is at
http://kyle.tk/binaural-beat-sample-64k.opus However, if I pass the "–uncoupled" option, sample at
http://kyle.tk/binaural-beat-sample-64k-uncoupled.opus Rockbox only plays a cacophony of chirps, scratches, squeaks and garbled noise, and no hint of the original sound is detectable.

Note: I have only been able to test this on a Clip+, as I own no other Rockbox player that is capable of playing Opus files at this time. Hopefully someone can confirm this problem on other targets, but for now, I have been able to reproduce it 100% on the Clip+, and I can confidently point to "–uncoupled" as the encoder option that results in an unplayable file.

After playing a few opus files (~128 kbps) the system becomes so unresponsive that it cannot decode the file in real time, and the device cannot respond to any input within a reasonable timeframe (have to hard power off).

This does not occur when you set the cpu frequency beyond the highest setting in the debug menu!

To reproduce:
play opus files in a playlist with normal cpu scaling
on beginning of 2nd or 3rd file, system will become unresponsive.

Create silence in Audacity program (Generate → Silence). Convert the wav file to ogg vorbis file. Put into the sansa clip+ player wav and Ogg files. Turn on the equalizer and set 32 hz, 64 hz, 125 hz in the 0.5-2.0.
Turn on maximum volume. Listen to the silence of wav file. Absolute silence. Listen Ogg Vorbis file - hear the noise (like the wind). It’s bug with only ogg vorbis. mp3, flac, mp4 is absolute silence.
On a musical files it’s additional noise. Ogg vorbis is economical of disk space. Testing on a sansa clip+ with 2GB.

Hi, this is a codec pack containing all codecs based on blargg's
Game_Music_Emu library.

I have ported all code to C to work in ROCKbox, and i have replaced the
MAME versions of some emulators with others compatible with the GPL license.
It was a lot of work but i did it because i really love chiptune music and having the
possibility to listen to a lot of classic video game system's music in a small player
is really great ;).

Original Game_Music_Emu library here: http://slack.net/~ant/libs/audio.html

Tested on: Sansa Fuze v2
Created from revision: 30084

The following formats are contained in the pack:

- AY (ZX Spectrum, Amstrad CPC)
- GBS (Nintendo Game Boy)
- HES (NEC TurboGrafx-16, PC Engine)
- KSS (MSX Home Computer, other z80 systems)
- NSF, NSFE (Nintendo NES, Famicom)
- SGC (Sega Master System, Game Gear, Coleco Vision)
- VGM, VGZ (Sega Master System, Mark III, Sega Genesis, Mega Driver, BBC Micro)

Additional features:

- 44100 Khz, stereo playback.
- Support all sound chips in NSF/NSFE formats.
- Support MSX-AUDIO and MSX-MUSIC in KSS format .
- Support ADPCM samples in HES format.
- Support for extended m3u playlists created specially for

some chiptune formats.

Known issuses:

- Some (or all) codecs might not work in some targets, specially

if they have an small iram size, or if the codec is too cpu intensive, 
like VGM and KSS.

- Subsong change is not working properly, specially when it happens

automatically.

- Most vgz tracks will be truncated due to the small amount of free

memory available to uncompress them.

- Some SCC+ soundtracks might not work correctly.

** There might be several bugs and issues to be found yet, so please feel free to

  report them here or to my mail address.

Special thanks to:

- Shay Green (blargg) the original author of the great Game_Music_Emu

library.

- Chris Moeller (kode54) who made some nice improvements to the library.
- Mitsutaka Okazaki, author of the YM2413 emulator.
- The OpenMSX team for the YM8950 emulator.
- Stéphane Dallongeville for the YM2612 emulator.
- Joshua Chang, Haiku Konaru and everyone else who has helped me to

test the codecs.

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.

This patch resorts the v-array within mpc’s synthesis filter. Through this data is placed more locally for the performance critical function mpc_decoder_windowing_D() and allows ldm-usage in the asm’ed parts.

This first patch does work for simulation but not for ARM or CF builds. An update with more optimized ARM asm will follow, CF asm needs to be corrected by someone with knowledge on CF assembly.

The output is binary identical.

When playing music, I can hear codec errors in the music. It occurs every time on a certain song, and other songs that are smaller in file size, it does not occur on, but occurs on the next one. I believe it is a buffering issue, and makes the music unlistenable. I used the daily on 10/21/2015

On 320kb/s MP3s it occurs much more often, and 128kb/s MP3s it occurs less often, but when it occurs its a series of glitches that distort the music.

I am sure its not the MP3s themselves, because it doesn't occur in the official firmware, and when I rewind it, it does not make the same sound until later. It has a very prominent 'glitchy' sound and later it changes the speed of the song.

I replaced it with the 3.1.3 MP3 codec, and the same glitch occurs.

I do not have a line out so its made through the speaker, but the problem is so bad that you can hear it very clearly.

The MP3 was 320kb/s

Memo is the glitchy one, and Memo-1 is it being played correctly.

When listing to a mp3 for some time there starts a massive random noise in the background. It will continue for some time when pausing or stopping playback and will also continue when starting another track.
I’ve noticed this when listening to a random list of mp3s of various sources and using speedup with 225% or 250%.

At the moment I’m using ee758c5 with my clip+.

Please refer to forum post for full exchange: http://forums.rockbox.org/index.php/topic,52518.0.html

In summary playing ALAC will crash the unit, other codecs not as much. My reasoning is (as contained in the forum post):

Converting some of my ALAC collection to FLAC to test has given excellent results = no crashes. I am suspicious of the ALAC decoder; watching the VIEW BUFFERING THREAD there seems to be consistency:

OGG/MP3/FLAC/WAV: CPU Frequency goes up to 124 until pcm: becomes full, then drops to 45mhz and pcm: hovers (it is always active) near the top of 100%. Upon track change the cycle starts again (124mhz until pcm: becomes full). I don't seem to get crashes.

ALAC: CPU Frequency goes up to 124 until pcm: becomes full, then drops to 45mhz and pcm: quickly goes down (takes about 2 seconds) to 75%, then cpu switches to 124mhz to get pcm: back up to 100%. This goes on constantly (cpu high - low cycle) while a single track/file is playing. I am now believing this cpu going up and down constantly gives me the crashes. Note on crashes: I don't know when they will happen, sometimes after a minute or two, sometime after 10 minutes , there is no pattern I can tell.

also category:
Some containers, like Matroska MKA or like Ogg can contain numerous audio tracks, for example the whole AudioCD contained within single Ogg file.

For example VideoLAN.org plays such files ok, while fails to show separate tracks/tags in playlist.

However, RockBox justs freezes and until reboot can no longer play music (each file is detected as having zero duration)

example can be found: [link deleted - it was a full copyrighted album]

When you play back a broken flac file (in this case a file that was truncated) it can happen that he decoder outputs constant loud noise instead of just skipping to the next track.

I’m not sure if this is really a bug since you are not supposed to play back broken files.

Attached is a file where this happens.

H300 r18009 (happens in the uisim too).