Rockbox

Tasklist

FS#11608 - Fuze v1 playback issues

Attached to Project: Rockbox
Opened by Orbidia (orbidia) - Monday, 06 September 2010, 23:42 GMT
Last edited by Fred Bauer (freddyb) - Tuesday, 07 December 2010, 15:45 GMT
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Operating System Another
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Sansa Fuze v1
Build r27996 r28001 and r28016

A few days ago, I installed the new 2.0 rockbox firmware on the fuze so that I could use the USB mode and not go into the official firmware anymore. The USB mode seems to work well enough.

But in build r27996 the thermometer indicating the playback position in the song did not work when using many of the themes (XL Fuzed for example).

So then I tried r28001 and r28016 the next couple days. Now, not only does the playback bar not work, but a lot of the time, the 320 mp3 files don't play back at all.

If I first turn on the player, and try to play a song, it works okay. But if I stop the song and try playing another song, often it will just show 0:00 for elapsed and 0:00 for remaining and nothing happens. One time, the song did play but the numer for time elapsed remaining kept jumping to random numbers.

Also, the battery gauge would jump between 98% to strange random numbers above 10000%
It crashed once just trying to playback. I've tried the last could builds on 3 different fuze v1 and they all had similar problems.

I'm back to r27996 because at least it plays the music.

It seems something generally broke in the last few builds and I was just trying to report the specific problems in case no one was aware of them.
This task depends upon

Closed by  Fred Bauer (freddyb)
Tuesday, 07 December 2010, 15:45 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in r28616 by switching CPU to asynchronous mode when boosted.
Comment by Rafaël Carré (funman) - Tuesday, 07 September 2010, 03:48 GMT
It works fine for me:
- playing a track
- stopping with long play
- playing another track from the filetree

With r28016
Comment by Manequin (manequin) - Sunday, 12 September 2010, 15:02 GMT
Same issue on Fuze v1. Last rockbox version that i saved on my computer harddrive and it's working is r27995. In every newer build playback is broken (I have only .ogg files). I have also installed bootloader 2.0 lately.
Comment by Rafaël Carré (funman) - Sunday, 12 September 2010, 15:07 GMT
Please detail what happens.

Also force CPU frequency to 284MHz in debug menu and see if it helps
Comment by Manequin (manequin) - Sunday, 12 September 2010, 15:59 GMT
Forcing CPU Frequency doesn't help. I noticed, that I have playback problems only with ogg vorbis files (my whole library is in ogg, so it's important issue for me), mp3 files are played normally. If I try to play ogg file i get glitches or white noise instead of sound, and elapsed and remining time on WPS are changing to random values. After trying to play few files I get an error on white screen:
"Data abort
at 30688D00
FSR 0x8
(domain 0, fault 8)
address 0xEA000002"
Actually installed rockbox version: r28060
Comment by Jakub Kowalski (iss) - Wednesday, 15 September 2010, 14:53 GMT
Ogg playback is still broken on r28090.

BTW Where can I find older daily builds? Current stable (3.6) unfortunately has broken recording - http://www.rockbox.org/tracker/task/11548
Comment by Rafaël Carré (funman) - Wednesday, 15 September 2010, 15:20 GMT
Just tried ogg vorbis on fuzev1 r28090 : works fine.

For daily builds go to "current build" on the left of website and then "Daily builds", but they only go back to 4 days.

Can someone who experiences the problem make his own build and then look for the address of data abort in the .map files?
Comment by Rafaël Carré (funman) - Wednesday, 15 September 2010, 15:21 GMT
BTW, please try to reset your settings (especially theme settings) to see if it could fix the problem
Comment by Manequin (manequin) - Wednesday, 15 September 2010, 17:05 GMT
I have just tried newest build (r28090), all settings default (new .rockbox folder) and problem still exist. However, I found one file on my player that works. It was converted with the rest of album, and should be encoded in the same way, but I can send somewhere two files to compare. After trying to play few files I get same error as before - Data abort at 30688D00.
I am pulling code from svn now, and I will be learning to compile it in few minutes, if I succeed, I will search for the addres you wrote about.
PS I'm sorry if there are mistakes in my posts, english is not my native language.
Comment by Manequin (manequin) - Wednesday, 15 September 2010, 17:15 GMT
I'm sorry, the one file, that rockbox played was .mp3. I thought that all files on sd card are vorbis files, but there are few exceptions.
Comment by Gerhard Zlabinger (gez) - Thursday, 16 September 2010, 05:21 GMT
I can confirm Fuze V1 playback issues of vorbis files in the current build (r28090). Single tracks play fine, but when listening to a whole album in sequence, I get white noise and crashes after a few tracks. After playing around with old builds I have archived on my player, I think the problem might be caused by r27776 /  FS#11533 . Builds before that commit seem to work fine.

However, as I don't have access to my computer and no regular access to the internet at the moment, I cannot nail it down to a specific revision.
Comment by Nils Wallménius (nls) - Saturday, 18 September 2010, 08:16 GMT
I've just played through several albums of ogg/vorbis on my fuzev1 with r28105 and had no issues at all.

Does this happen on all your ogg/vorbis files or just some? Are they very low bitrate?
Comment by Jakub Kowalski (iss) - Saturday, 18 September 2010, 10:18 GMT
I've just tried r28105 and it's still only noise.
It's on all my ogg files. Most of them I encoded myself with ~256 kbps VBR. I also tried samples from http://nigelcoldwell.co.uk/audio/ and all of them were played as noise too.

I've got r27995 from Manequin and it was almost good. Most of the time it worked well, but sometimes it just suddenly played noise instead of music. But if I rewinded track a bit it was back to normal.
It was random - the same track sometimes played without any problems and sometimes it broke.

There is one more symptom - at the begining of each track elapsed time shows random numbers and then after a while (2-3s) it's back to normal. It didn't happen in r27995.
Comment by Manequin (manequin) - Saturday, 18 September 2010, 10:38 GMT
Every file on my Fuze is between 96 and 192 kbps. I've just tried to play few files converted with different bitrates. As Jakub wrote, at the begining of the track (or just after rewind/fast forward) there is a white noise and elapsed and remaining time show random values. But after few second elapsed/remaining times are correct and white noise changes into music with a lot of glitches.

I'm also using r27995 and have similar issues as Jakub. I guess I'll have to convert all my files on player to mp3 for some time :/
Comment by Manequin (manequin) - Sunday, 19 September 2010, 19:03 GMT
I found when exactly ogg playback broke down. I compiled svn revisions from 27995 to 28002 and last version playing vorbis files on my fuze was 27999. On 28000 and newer it behaves as I have described earlier. In 28000 power saving patch was merged: http://www.rockbox.org/tracker/task/11597
Comment by Rafaël Carré (funman) - Sunday, 19 September 2010, 19:15 GMT
Can you double check again that forcing cpu frequency to 248MHz doesn't fix it?
Comment by Manequin (manequin) - Sunday, 19 September 2010, 19:31 GMT
Yes I did, it didn't help.
Comment by Manequin (manequin) - Sunday, 19 September 2010, 19:38 GMT
I have just pulled 28116 from svn and manually reverted (I now it's not a good way) all changes from 28000 in files: firmware/export/config/sansafuze.h, firmware/target/arm/as3525/clock-target.h, firmware/target/arm/as3525/system-as3525.c, compiled and installed on my fuze. Everything is working fine now.
Comment by Rafaël Carré (funman) - Sunday, 19 September 2010, 20:25 GMT
Can you try this patch?

BTW you can save your modifications like this:
$ svn diff > ~/backup.diff
$ svn revert -R .
$ patch -p1 < ~/disable_cpufreq.diff
......
$ svn revert -R .
$ patch -p0 < ~/backup.diff
Comment by Manequin (manequin) - Sunday, 19 September 2010, 20:43 GMT
Sorry, noise and data abort.
Comment by Andree Buschmann (Buschel) - Friday, 08 October 2010, 14:17 GMT
I am following the discussions in the forum for a while. If I understand everything right the issue is as follows:
r28000 introduces problems on several individual targets. Somehow those problems are not reproducible by the main developer for this target. Therefor he cannot fix those issues right now. This can happen.
r28000 was made to reduce the power consumption of the target and allows higher battery runtime.

So, it is finally a question whether our Trunk focusses on stability or runtime for the discussed target.

I would prefer stability over runtime for all users. A patch that allows better runtime could be provided for those who are able to build rockbox on their own and who are not affected by the issue described above in this flyspray entry. The flyspray entry that contains such patch can be used to find a solution that also works for the users with a problematic hardware.

If there is no consens the final decision should be made by the rockbox steering board. That's what it's for.
Comment by Rafaël Carré (funman) - Friday, 08 October 2010, 14:41 GMT
the problems are not reproducible by any developer, not only by me

also i think trunk is for developers, not stability
USB was disabled for several targets (sansas PP? also ipods?) in releases but left activated in trunk so development could continue
-> we can do the same thing

Also please don't mention the RSB because I take that as an insult
The RSB is only needed when there is a conflict and I see no conflict here, only developers who were not aware of this bug report, but nobody looked like they had a problem with me (and i certainly don't have a problem with the other devs)
(BTW thanks for trying to sum this up, it can be useful since the information was spread on this bug report, the forums, the mailing list, and in my head)

Please keep this bug for technical discussion.
If you have a problem with me not wanting to revert r28000 then it's not a technical issue and should be brought to the mailing list (not the forums because they are much harder to follow)
Comment by Rafaël Carré (funman) - Friday, 08 October 2010, 14:42 GMT
If someone want to help seeing this bug fixed, please send me one of the problematic Fuze so I can reproduce the problem

My 2 Fuzev1 work fine with mp3 and vorbis
Comment by Andree Buschmann (Buschel) - Friday, 08 October 2010, 14:55 GMT
> Also please don't mention the RSB because I take that as an insult
Sorry, if you got this wrong. I definately do not want to insult you -- I just wanted to search for a way to receive a general guideline how to proceed with stability vs. functionality.

Btw, you mentioned the USB thing. An idea to cope with issue might be to make a release w/o r28000 and keep r28000 on Trunk. Or -- even more -- to revert it on Trunk until 3.7 has been delivered.

Maybe we can discuss and decide this in irc very quickly :)

Last non-technical post from my side in this thread.
Comment by Michael Chicoine (mc2739) - Friday, 08 October 2010, 17:43 GMT
FWIW, r28000 does not cause any problems on my e260v2
Comment by Orbidia (orbidia) - Saturday, 09 October 2010, 09:41 GMT
Me and my family have 5 Fuze v1s and 2 Fuze v2s. At least two of them exhibit problems with r28000 and later.
One of them in particular does not work well at all with the r28000 changes.

Flac playback on this player is totally distorted with beeps and buzzing. Also I get a lot of very strange number flashing as described in the original post.
Maybe some people can try this:
Start a Flac song playing and simply fast forward through a bunch of the song and then rewind to near the beginning. On my player, it may seem to be alright at first but after 5-10 times of FF/Rewind, random large numbers start flashing where the Played Time/Remaining Time is located.
I also detailed how changing the CPU frequency itself with r28000 and up immediately causes weird random numbers on the setting screen.
And then it will usually crash later with a similar report as Manequin.

Funman, if you would be willing to test it out, I don't mind sending you my "bad apple" Fuze v1.
E-mail me to discuss that option.
Hopefully, the issue can then be resolved before the final Rockbox 3.7.
Comment by Tobias Diedrich (ranma) - Saturday, 09 October 2010, 09:45 GMT
FWIW I tried v28220 on my Fuze v1 and haven't seen problems so far. (Tried both ogg and mp3)
Comment by Orbidia (orbidia) - Saturday, 09 October 2010, 09:49 GMT
Funman, I could also meet you on IRC if that is more convenient to discuss sending you my Fuze v1.
Comment by Rafaël Carré (funman) - Saturday, 09 October 2010, 09:56 GMT
Orbidia, sorry but working on this problem only gave me hate and anger, see http://www.rockbox.org/mail/archive/rockbox-dev-archive-2010-10/0031.shtml for example.

I'm not working on this bug anymore, ask Llorean or rasher on IRC to see this bug fixed.
Also ask them if they can fix it without reducing the battery life of some hours. Short answer: they can't.
Comment by Jakub Kowalski (iss) - Saturday, 09 October 2010, 11:22 GMT
Just want to add I tried latest build - 28220 - and the problem still exists. Then I reverted r28000 changes, compiled and problem was gone.
Battery life is important of course, but it's for nothing when most of my music can't be played.

If it help to narrow it down to some particular batch - mine is BH0807AXWK-4GB.
Comment by Frank Gevaerts (fg) - Saturday, 09 October 2010, 11:48 GMT
Maybe comparing rockbox settings could be useful?

orbidia: do those fuzes run with the same settings? If not, what are the differences?
Comment by Orbidia (orbidia) - Saturday, 09 October 2010, 12:51 GMT
I'm not sure what to say. I didn't want to cause hate and anger.
I realize Rockbox developers put a lot of time and energy into coding rockbox.
We users truly appreciate all the hard work. Its a wonderful piece of software. I love Rockbox Fuze so much, I bought 7 of them (many gifts) because me and my family plan on using them for many years. Between the sound quality of the Sansa and the Rockbox software, I don't need any of the new touchscreen stuff which is all the rage.

***** Without Rockbox, the Fuze would be pointless. *****

I could probably just use the Official r27999 or Manequin's later build with reverted changes and not bother upgrading ever again. I guess I could have just not said anything and been happy enough. I wasn't trying to cause upsetment.

But I guess I still want to use future Rockbox versions...

One of my Fuzes doesn't exhibit the problem. But when I played around with it, I did manage to make it glitch in a similar manner to my Fuze that does show the problem. I wouldn't have even noticed it if it wasn't for my "Bad Apple" Fuze. So I suspect this problem could be causing slight problems for some people but they are unaware of it. It is true that 3 different people are reporting problems that exhibit similar but different symptoms stemming from the same battery life code. Unfortunately, its not consistent so it will be more difficult to track down - especially when a developer apparently doesn't have a fuze that exhibits the problems!

Now, I personally haven't had a problem with the battery life on the Fuze. It could always be better but I'm satisfied enough. But I'm assuming a lot of work went into the code to make the battery life longer. I assume that's where the tensions come from.

I'm sorry that there are Fuzes out there that don't work well with the battery life savings.

If it turns out to just be a bug in the battery life savings code and it can be fixed - great! But if its something particular to a bunch of Fuzes and we can't use Rockbox on them... well, I'd rather have a lower battery life.

What to do?

If Rockbox 3.7 is around the corner, I don't understand why the battery savings code would still be included when more than one person has reported some bugs from that specific code. I'm sure a bunch of people who don't run daily builds will suddenly have problems with the Rockbox 3.7 "Stable" release. I guess that depends on how many "bad apple" fuze v1s actually exist.

Obviously, I'm all for Rockbox 3.7 without the battery savings code.

If the developers want to put the code back into the daily builds so people can test for a fix. I don't mind that at all. I guess I'll be happy enough as long as the Stable versions work correctly. But if the developers don't have a "bad apple" fuze to test... nothing will get fixed. It seems we're between a rock and a hard place.

I'm sure my Fuze v1 is one of the worst offenders. So the most I can do is offer my "bad apple" Fuze v1 as a loaner/trade to a developer. I could also shoot video and post on youtube or something if that would help.

If it helps, my fuze v1 batch is BI0910BMYK-8GB

Where do we go from here?
Comment by Jonathan Gordon (jdgordon) - Saturday, 09 October 2010, 13:13 GMT
It wasnt you who caused the anger..

arg, my fuzev1 doesnt have any problems with svn also
Comment by Orbidia (orbidia) - Saturday, 09 October 2010, 13:22 GMT
Frank,
When I test them, I just delete the entire .rockbox folder and copy the latest build over. So they would all be running the same default settings.

I believe I tried both the old firmware and the new USB enabled firmware and they both had the same problems.

I'm beginning to wonder if this has something to do with the quality of the battery itself? Like there's a threshold where on some players, the battery is not supplying enough juice with the new code? So maybe the memory generates errors which eventually corrupts and crashes the player. I don't know - this is just an idea. I guess the answer would be in exactly what the r28000 code changed in rockbox? And apparently, it has something to do with battery life savings.

I have one fuze that works quite well and one that works very badly. I think my sister has one that was also quite buggy. That's when I thought they all worked badly (but I was wrong about that). I haven't tested above r27996 on my Mom's or the other backup fuze... (That's all five Fuze v1 that I have available.)
Comment by Tobias Diedrich (ranma) - Saturday, 09 October 2010, 13:57 GMT
> If it help to narrow it down to some particular batch - mine is BH0807AXWK-4GB.

Mine (working fine so far) is BH0806AXWK-4GB, so it's quite close.
I compiled r28220 myself, renamed .rockbox to .rockbox_old and installed the new .rockbox (So I've got default settings, and did the first tests using that, but have since changed theme & font).
Comment by carl redman (darlredfish) - Sunday, 10 October 2010, 20:30 GMT
Changed formats to ogg vorbis (only use mp3) im now getting hollow sound with repeated beeps/static through out, along with my previous problem with the crossfade. I also noticed that ff/rw causes my position counter to drop back to all zeros before returning to where it should be.

BH0805AVUK-4GB - r28235
Comment by Orbidia (orbidia) - Monday, 11 October 2010, 01:04 GMT
Uh oh, darlredfish - you must have one of the bad ones! Usually, once the position counter starts messing up, it seems like things are getting corrupted. If you keep FF/RW, you may start to see the played/remaining time flash 10 digit random numbers. Everything becomes unplayable and eventually, the Fuze will just crash. Rebooting makes the problem start from scratch again.
In Rockbox, you could also try to go to:
System -> Debug -> CPU Frequency
and change "boost_counter:" from 0 to 1 or above. On my Fuze, with r27999 and below it is stable. But with r28000 and above, I immediately get crazy flashing numbers on the setting. I described it in detail in my forum post Reply #22: http://forums.rockbox.org/index.php?topic=25809.15

Could this problem be that as the battery gets old, it puts out a bit less voltage and battery life savings code makes it unstable? Even more significant to the "oldness" of the battery would be how often it was used, how it was charged, etc. Some people have a better battery charging regimen than others.

If that is the case, then potentially all the Fuzes will react badly with that battery saving code as the battery gets older... So it may be that my battery has been more abused than others? This could be possible.

So a couple more people have reported having the problem. Manequin already made an unofficial build which fixed the problem. What is happening with the official builds? Will at least Rockbox 3.7 have a fixed version?
Comment by Nils Wallménius (nls) - Monday, 11 October 2010, 06:48 GMT
This being caused by the battery is very unlikely, if it ouputs a too low voltage the low power protection will kick in and power off.
Reverting the commit that broke this isn't really a fix as it seems noone understands why it broke stuff on only some fuzes, that said, the release will probably have that commit reverted unless a proper fix is implemented.
Comment by Orbidia (orbidia) - Tuesday, 12 October 2010, 21:21 GMT
Nils,

Thanks for responding.

The "lower voltage" battery idea was just pure speculation on my part. Its too bad noone knows why the battery optimization code doesn't work properly on some fuzes.

Either way, if Rockbox has a proper "fix" or it just has "reverted" code, I look forward to when the official builds (or final v3.7) will work properly for me again.
Hopefully, someone reports here when a change has been posted in the official builds regarding this problem so I can try it out.

Obviously, the developers have already worked out the possibilities, so I'll just let it go now.
Comment by Thomas Martitz (kugel.) - Sunday, 17 October 2010, 16:43 GMT
Everything seems to work fine on my fuzev1.
Comment by Doru Barbu (fragilematter) - Sunday, 17 October 2010, 17:59 GMT
My e200v2 also seems to exhibit ogg playback problems on builds >= r28000. Independently of Manequin, I zeroed in on the FCLK power saving code to be the culprit and, for the time being, solved it by reverting firmware/export/config/sansae200v2.h, firmware/target/arm/as3525/system-as3525.c and firmware/target/arm/as3525/clock-target.h to their r27999 versions.

I have tested a variety of Ogg Vorbis audio, from Q7 files both encoded by me and by Jamendo to 22050Hz 56kbps podcasts, and they all sound like this:

http://dl.dropbox.com/u/389421/r28288-ogg.ogg

MP3 audio doesn't seem to be problematic, nor do the other codecs, but I haven't throughly tested them.

I will try to test other formats and see if there is any influence there and report any observations here.
Comment by MichaelGiacomelli (saratoga) - Sunday, 17 October 2010, 19:50 GMT
Can someone try decoding a file in test_codec to WAV (you'll need to add test_codec.c to apps/plugins/SOURCES and then compile a build with it) ? It would be interesting to know if the resulting wav sounds better or worse then playback on the device.

All my AMS players work fine, so I can't test.
Comment by Doru Barbu (fragilematter) - Sunday, 17 October 2010, 20:35 GMT
I have compiled a build with test_codec, but I can't seem to get it to work.
I repeatedly received a "Divide by zero at 30687778" error when trying to write wav, with or without dsp, although not at the same place.
Also, before crashing the progress indicator displayed weird stuff like "( of 188080", "- of 188080" or a very large integer, abnormal values which were "corrected" when the progress indicator iterated.
Upon reboot, the test.wav file is always 0 bites in size.
Comment by Doru Barbu (fragilematter) - Monday, 18 October 2010, 08:58 GMT
Assuming that vorbis.codec is loaded there, the relevant memory map entry would be ".text 0x3068756c 0xab0 /home/doru/Development/rockbox/build/apps/codecs/libtremor.a(floor1.o)"

As to the contents of floor1.c, the C code in there is way beyond my skills, but the only explicit division that I could find and for which the divisor could be zero is in render_point(), line 197.
Comment by MichaelGiacomelli (saratoga) - Monday, 18 October 2010, 14:33 GMT
A divide by zero is weird. If the memory or disk corrupted the file, I'd expect it to get garbage and crash immediately with an undefined instruction. Not sure how it would change a value to zero without screwing up the rest of the code :)

Could you try test_disk and see if that works?

Also, it might be neat to know if WAV files played on the device sound as bad as compressed audio.
Comment by Doru Barbu (fragilematter) - Tuesday, 19 October 2010, 19:22 GMT
I eventually managed to coax rockbox into writing a test wav for ogg by encoding the first 30 seconds of http://download.rockbox.org/test_files/flac_5.flac into an ogg q7.
It looks like the noises and pops are greatly aggravated compared to regular playback, you can hear it here:

http://dl.dropbox.com/u/389421/30sec_ogg_test.ogg

In the mean time I've managed to pull down the audio files that are used for the codec benchmark and test them. This is what I've found:

64aache gives a "codec failure" immediately after starting playback. test_codec->write wav ends in about one second with no error message, and the resulting wav file also contains about one second of audio.

ape_c1000 - ape_c4000 all give white noise when played back. With test codec I got mixed results. Several times it locked up the player with no error message. One time ape_c3000 resulted in a "Divide by zero at 30681A84", which corresponds to "0x30681168 entropy_decode" from apps/codecs/libdemac.a(entropy.o). When ape_c3000 and ape_c5000 succeed, and the wavs were white noise, solid for c5000 and with short interruptions for c3000. You can hear the resulting audio below, but set the volume *VERY LOW* before opening them.

http://dl.dropbox.com/u/389421/ape_c3000_test.ogg
http://dl.dropbox.com/u/389421/ape_c5000_test.ogg

Musepack resulted in an error each time. The error messages were the same for playback and test codec, and they didn't change with subsequent runs.

mpc_096:

Data abort at 30680FCC
FSR 0x8 (domain 0, fault 8)
address 0xB0689689

mpc_128:

Data abort at 306814EC
FSR 0x8 (domain 0, fault 8)
address 0xB0689FC2

mpc_170:

Data abort at 306814EC
FSR 0x8 (domain 0, fault 8)
address 0xB068B441

mpc_224:

Data abort at 306814EC
FSR 0x8 (domain 0, fault 8)
address 0xB06893A0

mpc_300:

Data abort at 306814EC
FSR 0x8 (domain 0, fault 8)
address 0xB06897FC

mpc_350:

Data abort at 30681B6C
FSR 0x8 (domain 0, fault 8)
address 0xB068D831

All the errors correspond to "0x30680dbc mpc_decoder_read_bitstream_sv7" from apps/codecs/libmusepack.a(mpc_decoder.o)

For the other files/codecs playback seems to be ok, but I didn't do a very through check, nor did I try test codec.

I don't know what to make of this, but it doesn't seem to be related to the audio output side.
Comment by Orbidia (orbidia) - Sunday, 31 October 2010, 05:45 GMT
To the Rockbox developers,

I have been playing with Rockbox 3.7 for about an hour now. I don't know if there was a fix or a revert to the r28000 problem code for the Fuze.

All I know is that I have the latest stable version. When I boot up, I see Ver. 3.7 and everything is VERY STABLE. I've tried a number of FLAC tracks which had major problems playing back on the builds over r28000. The sound is now as phenomenal as I expect from Rockbox.

I also tried the FF/RW trick and I don't get any weird numbers at all in the Played/Remaining Time fields as I described in the original post.

Everything works great again.

If the problem was corrected with a revert, and someone wants to try to actually fix the original battery saving code, I will be happy to test any build to make sure it works on my particularly sensitive fuze v1.

I just wanted to say Thank You for making Rockbox and also especially Thank You for resolving this specific problem for r3.7.
Comment by Jonathan Gordon (jdgordon) - Sunday, 31 October 2010, 12:20 GMT
yes, r28000 was reverted in the 3.7 branch... hopefully an actual fix comes for the next release.... (well, we can dream anyway)
Comment by John Romero (sssUSER) - Monday, 08 November 2010, 00:21 GMT
Funman you are dyslexic, it's 248MHz not 284MHz, the AS3525A/B has a max CPU clock frequency of 250MHz according to the distributor's datasheet.
Quote:
"Comment by Rafaël Carré (funman) - Sunday, 12 September 2010, 17:07 GMT+1
Please detail what happens.

Also force CPU frequency to 284MHz in debug menu and see if it helps"
Comment by Jonathan Gordon (jdgordon) - Monday, 08 November 2010, 00:26 GMT
He mistyped, did you try it and see if it helped?
Comment by John Romero (sssUSER) - Monday, 08 November 2010, 01:33 GMT
I don't have the problem.
Comment by Fred Bauer (freddyb) - Friday, 12 November 2010, 17:43 GMT
Sorry if this is redundant, but here's a reverse patch for r28000 ( FS#11597 ). On mine the mp3's play ok but vorbis is messed up.
Comment by Fred Bauer (freddyb) - Friday, 12 November 2010, 20:31 GMT
This fixed my problem. I switched from synchronous to asynchronous bus clocking. Is there any significant downside to using async?
Comment by Doru Barbu (fragilematter) - Thursday, 18 November 2010, 13:27 GMT
I can also confirm that async bus clocking fixes everything on my e200v2, tested on r28608 with other patches that I keep in my repo, and on a freshly checked out r28612.
Comment by Fred Bauer (freddyb) - Thursday, 18 November 2010, 16:49 GMT
The last patch was committed to SVN. Can people test and give feedback? Thanks, Fred
Comment by Sendy Friedlander (yelped) - Thursday, 18 November 2010, 18:28 GMT
IIRC correctly this affects battery life. I'll give it a try and see.

Thanks a lot Fred!
Comment by Basil (ku-ku) - Friday, 19 November 2010, 05:49 GMT
The patch did solve the problem with ogg files.
Comment by Fred Bauer (freddyb) - Friday, 19 November 2010, 19:07 GMT
Yelped: I hope this doesn't affect battery life. It doesn't undo the main change of r28000, it just puts the cpu in async operation.
Comment by Orbidia (orbidia) - Wednesday, 24 November 2010, 02:03 GMT
"The last patch was committed to SVN."

Does this mean the "async fix" is contained in the current builds?

I'm testing the current build r28650 and everything seems ok.

So if re28650 has the battery saving optimizations of r28000 but uses the async fix, then I guess this is a true fix if it works for everyone else.

The question is:
Does putting the fuze in async use up more battery life than the r28000 optimizations saved?
Comment by Orbidia (orbidia) - Wednesday, 24 November 2010, 02:05 GMT
Does the official firmware use sync or async mode?

Are there any other side effects of async operation?

Comment by Fred Bauer (freddyb) - Wednesday, 24 November 2010, 03:43 GMT
Orbidia, yes, I committed the async fix to SVN which affects current builds. Funman's r28000 improvement is still there with a very minor tweak. I suspect that using synchronous mode causes the peripherals to get a bunch of bus delays because they have lower bus priority and everything hits the bus at the same time. i.e. the peripherals have to squeeze in bus access when the CPU doesn't need it, and the CPU might be asking for lots of consecutive bus accesses while decoding.
Comment by Fred Bauer (freddyb) - Thursday, 25 November 2010, 02:58 GMT
Ok, I was going to switch the bus priority to test my theory but it was already flipped. I still think the problem was bus starvation, though.
Comment by Orbidia (orbidia) - Thursday, 25 November 2010, 07:32 GMT
Fred, I don't really understand the intricacies of CPU cycles but with more testing on r28650, I still haven't seen the problem.
So I think you may have fixed the problem.

Maybe we can all now enjoy the effort Funman put into the battery life optimizations.

But it still needs to be tested whether async cpu with battery optimizations (r28650 and greater) has better or worse battery life than sync without battery optimizations (Rockbox 3.7).

Also it should be tested if there are any other side effects of async operation - although I haven't seen any yet with somewhat brief testing. I will continue stress test different things like crossfeed/eq with FLAC etc which will load up CPU cycles.
What is the most stressful situation in Rockbox for the CPU? Just load up all the audio filters possible and play a demanding FLAC? Would that be a good way to test?
Comment by Fred Bauer (freddyb) - Monday, 29 November 2010, 02:38 GMT
"Maybe we can all now enjoy the effort Funman put into the battery life optimizations." I have been. :) I really don't expect any difference in battery life from Funman's to the tiny change I made. The CPU spends most of its time running in fastbus mode. It only uses sync or async when boosted, which is not so much. Even then, the power difference shouldn't be significant.
Comment by Orbidia (orbidia) - Thursday, 02 December 2010, 02:48 GMT
Fred, did the async fix make it into the Rockbox 3.7.1 final with the r28000 optimizations?

Comment by Fred Bauer (freddyb) - Thursday, 02 December 2010, 15:09 GMT
Orbidia, no. Neither r28000 or my patch are in 3.7.1.
Comment by Fred Bauer (freddyb) - Monday, 06 December 2010, 16:01 GMT
Is anyone still having problems? Should this be closed?
Comment by Manequin (manequin) - Monday, 06 December 2010, 16:30 GMT
Everything works excellent for me :)
Comment by carl redman (darlredfish) - Tuesday, 07 December 2010, 03:00 GMT
Working fine on mine.

Loading...