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

   I've update my ipod nano 2G to r23629. I found the clickweel would remember the last point my finger leave. And next when I touch the clickwheel, it will make a farward/backward move according to the last point I left, even click the button. Now it is not convenient to type a word with the keyboard inside or setting.
   And my Mac doesn't launch my ipod when I connect my ipod with USB until I change to disk mode. Seems that the USB driver doesn't work.

This isn't a big problem because the MR-100 won't turn on if the hold switch is already engaged.

But if the user turns on the MR-100 and then engages the hold switch while the M:Robe logo is on the screen, a "Hold switch is on Shutting down…" message is displayed, but it does not shut down.

A reset is required at this point - disengaging the hold switch and holding down the power button in this state does not shut down the MR-100.

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.

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.

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

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.

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

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.

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

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

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

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.

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!

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.

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.

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

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.

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.

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.

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

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.

Playing APE 24/44.1 with harsh noise in different parts of the track. If you decode APE file to WAV using the codec console, then there are no problems. So the matter is in the player’s APE decoder.

At 24/48 everything is fine.

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.

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.

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

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.

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.

There is an ALAC playback problem in daily builds (since 2014-11). The playback somethimes works for one song but then crashes and shows ALAC file details as "? kbit/s", "0 MHz", "0 MB" and nothing happens when I press the Play button. After reboot the problem occurs again. It makes the ALAC playback impossible.

Now I'm using revision 9cb9f76M-140326 with patches from aroldan:

https://www.dropbox.com/sh/b5xbw6cp4ikfxwn/MjELjmDNJ_

With this build there are no ALAC playback problems.

http://www.konscience.de/wp-content/uploads/kns017-maertyrer-gegen-copyright.m4a

The current build as well as 3.13 report and then fail:

parsing /kns017-maertyrer-gegen-copyright.m4a failed (format: ALAC)

However, foobar reports:

Codec profile : AAC SBR

Which is likely correct given that the bitrate is far too low to be ALAC.

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.

First noticed the issue in the previous dev build, and just confirmed in 15fa7f8.

When playing .opus files, no metadata is displayed. Some files (92kbit stereo music files so far) do play fine otherwise. Others induce crashes upon attempting to play. An example is attached.

First test, I played a couple of music files successfully, then tried to play the attached file. System crashed immediately showing the following:
“Undefined instruction
pc:30000002 sp:300632[display cuts off here]
bt end”

Powered off, restarted, and tried to play the attached file immediately. After a second or so of audio, player crashed again:
“Undefined instruction
pc:08180002 sp:302029[display cuts off here]
bt end”

On the previous dev build, I was getting similar errors if I tried to play the attached file (or several other similar ones) after successfully playing other files, but would get a black-screen crash if I tried to play it immediately on powerup (this is not what is happening on 15fa7f8).

I am NOT experiencing these problems on another AMSv1 player (Sansa c240 [”c200v1”]) with the same dev build, so this may be specific to the Clipv1. On the c240 with both the previous build and 15fa7f8, metadata displays fine and the attached file plays without any apparent error.

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

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.

as3525
Version: 91b52a1-120122

Running on Sansa clip zip, unable to play the following .ogg file (I can't try it on other Rockbox versions, maybe someone can?). Works fine played any other way.

www.quik.clara.co.uk/Wontplay_inrockbox.ogg

(too large to attach directly)

When playing a sequence of two songs Rockbox on my HTC Desire S always crashes. I first had r30576-110921, and now it is r31516-120102. Cropped versions of the songs can be downloaded here:

http://www.vlado-do.de/rockbox/01_Wenn_die_Nacht_am_tiefsten_03m_08s_09h__03m_23s_22h.ogg http://www.vlado-do.de/rockbox/02_Wir_m%C3%BCssen_hier_raus_00m_00s__00m_28s_82h.ogg

They still reproducably crash my Rockbox. I found a workaround, though: mp3 versions of the same songs play all right. Rockbox for me still is the only known way to have gapless playback on my phone. Thanks for that guys!

Buy the way: the same ogg files made no problem in Rockbox on my old iPod nano.

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

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…

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

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 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 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!

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

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.

Hardware: Clip+ 8GB using internal memory
Problem: Playback of most APE files results into passages of loud noise during playback. The music is totally gone and noise is ear deafening loud. When rewinding, till music is heard, and replaying the problem part, error can be reproduced _sometimes_.
In other cases it either runs fine, or the problem occurs elsewhere in the file.

Since the problem does not always occur in a specific part of a APE file, it is hard to attach a sample file.

Problem persisted between ape files encoded in high and normal setting.
Using winamp + monkey audio 3.99 APE plugin, these files never shown problems.

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.

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.